similar to: two potentially troubling posts to full-disclosure

Has anyone around here heard of this ? ---Mike >Subject: Re: [Full-Disclosure] new ssh exploit? >From: christopher neitzert <chris@neitzert.com> >Reply-To: chris@neitzert.com >To: full-disclosure@lists.netsys.com >X-Mailer: Ximian Evolution 1.4.3.99 >Sender: full-disclosure-admin@lists.netsys.com >X-BeenThere: full-disclosure@lists.netsys.com

I'm a college student, but I also have an private network behind my firewall at college, and I have an ipsec tunnel to my office. I had to recently use the printer port on my firewall, so I ended up installing samba, and told it only to talk to my office network. Well, it managed to pick up the browser list..... and it got ahold of a local browser role as soon as it came up because I have a

I did testing on generating this report from a 130 MB Quickbooks file. Locally, 15 seconds. Samba Server, 1:35. Shared off of my win98 Workstation, 2+ mins. I do not understand the reason it is SOO slow. I know it is a fairly large file. The only explanation I can come up with is the way QuickBooks is accessing the files. Maybe jumping all around the file, requiring many operations on the

From what I've read on the list, there does not appear to be POSIX ACL support for rsync at this time, is this true? There does however appear to be a patch floating around out there, where can I find this patch. TIA -Justin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a

On Tue, Sep 25, 2018 at 11:48 AM Zube <Zube at stat.colostate.edu> wrote: > > The current mitigation for CVE-2018-14634 is a systemtap script > mentioned here: > > https://access.redhat.com/security/cve/cve-2018-14634 > > It also mentions that one can build a kernel module to distribute > to other machines, but in any case one needs the corresponding > debuginfo

On Tue Feb 16 03:35:06 PM, John R Pierce wrote: Thanks to both you and Mark Roth for chiming in and thank you for the lsi-raidinfo script. > On 2/16/2016 3:23 PM, Zube wrote: > >Does anyone know what program can be used to query the RAID status > >from the OS for an on-board LSI SAS 2308-4i? > > the 2308 isn't actually a megaraid, Right, that is in agreement with both

The current mitigation for CVE-2018-14634 is a systemtap script mentioned here: https://access.redhat.com/security/cve/cve-2018-14634 It also mentions that one can build a kernel module to distribute to other machines, but in any case one needs the corresponding debuginfo packages to do either. After enabling CentOS-Debug.repo, what I get is:

On 06/01/18 12:00, Zube wrote: > On Sat Jan 06 12:27:22 PM, Danny Smit wrote: > >> I normally certainly prefer the stability of the long-lived releases. >> I noticed an update was just released of the long-lived release: >> 384.111. The notes for this release say: >> >> Fixed a regression that prevented displays connected via some >> types

Good Day. In June, I posted a small query under the Subject of _odd smbpasswd / smbclient error from Linux to Solaris_ Briefly, a Solaris sparc server running 3.0.25a would not accept passwords from the Linux smbclient program if the password was 9 characters or greater. Instead, one would get this: session setup failed: NT_STATUS_LOGON_FAILURE but it worked fine with the Solaris sparc

Two identical machines, both running CentOS 4.3 plus all the errata. First one: yum update went for a while and hung. At the bottom of the yum.log file was this: Aug 31 06:58:01 Updated: control-center.i386 1:2.8.0-12.rhel4.5 Aug 31 06:58:09 Updated: iiimf-le-unit.i386 1:12.1-13.EL.5 Aug The python process was in the process list, but it was consuming no CPU time. I let it go for a couple

Never had much trouble building on the Mac until this round. Trying to build 7.4p1 with openssl 1.0.2j on a MacOSX 10.12.2/3 machine. gcc --version returns clang-800.0.42.1. This is the latest Xcode. Builds fine. Upon running sshd, it seg faults with this in the logs: assertion failed 16C67: libsystem_trace.dynlib+76912 [5BD4ECD4-75CA-38EA-AF5C-B481C15955F8]: 0x0 If I run the tests, it

On Sat Oct 22 08:20:24 PM, Valeri Galtsev wrote: > I should have said CentOS 7. Older ones (CentOS 6 and 5) are not vulnerable. https://bugzilla.redhat.com/show_bug.cgi?id=1384344 Comment #35 points to a link that doesn't depend on /proc/self/mem and claims to work on CentOS 6 and 5. I'm not quite sure what I should be looking for when I run the program, though. I do hope Redhat

Twitter user stintel, in this thread: https://twitter.com/stintel/status/948499157282623488 mentions a possible problem with the new patches and the nvidia driver: "As if the @Intel bug isn't bad enough, #KPTI renders @nvidia driver incompatible due to GPL-only symbol 'cpu_tlbstate'. #epicfail" Also: https://twitter.com/tomasz_gwozdz/status/948590364679655429

Sorry for the bother, but is there any way to poke or prod or query dovecot so that it will reveal what version of SSL it is currently using? dovecot --build-options tells me that openssl is there, but not the version. ldd on any of the binaries in libexec comes up empty. I can get the version and what directory it is looking at by: strings ssl-params | grep -i ssl but that is kludgy.

Good day. Thanks in advance for any help. I have a Tyan S2895 (Thunder K8WE) with 2 275 Opterons and the latest (1.02) bios. It appears to have an nVidia nForce SATA chipset which connects to a 250gb WD Caviar SATA drive. Using the CentOS 4 update 2 x86_64 DVD, the install is peachy until half-way through the "performing post install configuration" bit. Then it hangs forever. I

On Sun, Oct 28, 2018 at 03:54:06PM -0600, Zube wrote: > > Le 28/10/2018 ? 22:10, Albert McCann a ?crit?: > > > > Red Hat would stay as a distinct entity inside IBM. IBM has also > > contributed to Free software, and especially Linux kernel. > > I don't know how bad it is and the implications for CentOS... > > That old war wound started aching again. >

yum update was killed at an inopportune time, leaving ipa\* and xorg\* in an inconsistent state. yum-complete-transaction looks like it it's going to erase the entire system and then fails. >From the transaction files, the following are in: install 0:ipa-python-2.2.0-17.el6_3.1.x86_64 install 0:ipa-client-2.2.0-17.el6_3.1.x86_64 install

On Fri, Jul 27, 2012 at 2:37 PM, Michael Gottesman <mgottesman at apple.com> wrote: ... > I have actually timed said instructions in the past and reproduced Agner > Fog's results. I just prefer to speak by referring to facts that can not be > misconstrued as hearsay = ). That would be great. Also, can you point me to the Agner Fog table that you are referring to? Thanks.

I have a lot of experience, all of it pretty good, with various Sipura products, Grandstreams, Zultys, IAXy, and numerous SIP/IAX soft phones connecting into Asterisk as clients. Good sound quality, great reliability. I've tried two of the units named in the subject line, and frankly I'm frustrated. Calls usually start out OK, but within a brief period the sound goes totally to

I would prefer the behavior was different to what it is of I/O stopping. The argument I heard for the long 42 second time out was that MTBF on a server was high, and that the client reconnection operation was *costly*. Those were arguments to *not* change the ping timeout value down from 42 seconds. I think it was mentioned that low ping timeout settings could lead to high cpu loads with many