Date: Wed, 22 Jul 1998 11:56:03 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Brett Glass <brett@lariat.org> Cc: Jim Shankland <jas@flyingfox.com>, ahd@kew.com, leec@adam.adonai.net, security@FreeBSD.ORG Subject: Re: hacked and don't know why Message-ID: <Pine.BSF.3.96.980722115146.15193E-100000@fledge.watson.org> In-Reply-To: <199807220613.AAA26581@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Only if it is a kernel based buffer overflow. Userland buffer-overflws would not have this effect. They hose the one application, not the system. BTW, in the BSD 4.4lite design book, there is a footnote on the page describing the transfer of "rights" (file descriptors) via unix domain sockets. It indicates that the unp_gc() functionality does not mark transferred file descriptors as reachable in a situation involving accept on a listening socket. It seems like it might be possible to abuse this to steal file descriptors from other processes -- that is, if you still have a valid cmsghdr entry for the file descriptor, but that the file descriptor was garbage collected, the unp_externalize call might end up giving you a reference to a file descriptor owned by someone else (that was allocated shortly after the unp_gc() call). If you ran the right programs at the right times, you might be able to race yourself a copy of a file descriptor (with good creds) referring to the password file, etc. If you just got a bad fd, you might be able to crash the kernel or such. I've been rewriting sections of the unp_externalize behavior to allow lkm hooks for my ktokens code, and also found one or two other bugs in that code. I've fixed one and will submit patches for that (it could result in a kernel crash, but I'm not sure, as it's in the process's kernel stack), but if someone wants to audit kernel code, that might be a good place to check. On Wed, 22 Jul 1998, Brett Glass wrote: > The symptoms aren't hard to understand. As I found out when we > were hit by the same hack, buffer overflow exploits also > hose memory.... The disk cache, kernel data, possibly even page tables > can be corrupted. Nothing's safe. If you do anything to your file > system before rebooting, you can wind up with corrupted directories > and worse. This happened to us. > > --Brett > > At 10:36 PM 7/21/98 -0700, Jim Shankland wrote: > > >"Lee Crites (ASC)" <leec@adam.adonai.net> writes: > > > >> In my case, the bin directories (/bin, /sbin, /usr/bin, > >> /usr/sbin, etc) were still there, just that every program was > >> replaced with the exact same "dummy" program. All were, as I > >> recall, around 180k (exact same size with cmp showing no > >> differences in any of them. The funny thing is that ls did what > >> ls was supposed to do, ps did what it was supposed to do, etc, > >> even though they were the same size and cmp'd as identicle. > > > >I *definitely* want to know how to squeeze every executable in > >/bin, /sbin, /usr/bin, and /usr/sbin into one 180KB file. I'll > >bet Jordan would, too, if he hadn't foresworn working on sysinstall :-). > > > >The symptoms you describe (not counting the blow to the head), as > >well as Drew's, make me think "filesystem damage due to failing/flakey > >hardware" before "security compromise." Can't say for sure, > >of course; and in both cases, the evidence is gone. But I think > >you may be jumping to conclusions a bit to assert, "We were hacked > >like this two weeks ago." > > > >Jim Shankland > >Flying Fox Computer Systems, Inc. > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980722115146.15193E-100000>