Subject: buzz
To: None <port-mac68k@netbsd.org>
From: T@W <lsp93@xs4all.nl>
List: port-mac68k
Date: 07/07/1999 21:37:59
--============_-1280744880==_ma============
Content-Type: text/plain; charset="us-ascii"
I don't know if any of you has been following Bugtraq lately but here are
some recent posts (from Stealth & Darren Reed) regarding (net)bsd.
I'm still too much of a new-bee to know if it really touches our port, but
here it is:
>'The design and implementation of the 4.4 BSD operating system'
>page 263:
>
>"... Security levels are defined as follows:
>-1. [...]
>
> 0. [...]
>
> 1. Secure mode: The superuser-settable immutable and appned-only flags
> cannot be cleared; [...]
>
> 2. [...]
>
>"
>
>That's not true. You can do it either with fsdb or with the appended
>exploitcode. Sorry for that fat mail, but the code is not upload on my site
>yet, but i guess you also will find it there soon...
>The README describes exactly why you can erase these flags in level 1.
>I already send it to some friends and we found it working at least with
>FreeBSD (3.1). I guess that this is a general problem. perhaps someone
>verifys this on other BSD's too.
>
>Solution
>--------
>
>If fileflags are part of your security-concept, use security level 2, not 1.
>(sure, level 2 might also have been broken...)
>I might add that to be able to unmount /usr, if that is indeed where
>/usr/bin/login is being run from, or any other filesystem for that
>matter, it needs to be totally unused. For this reason, I think you
>would be hard pressed to have /usr unmounted in a manner that would
>go undetected unless you were in single luser mode. Depending on
>what else runs on the system and how packages are installed, the
>same might be true for other file systems often used for installation
>of binaries (/usr/local). To give you some idea of the programs which
>would need to have been stopped before unmounting /usr are as follows:
>
>syslogd, update, cron, inetd, getty
>
>(according to NetBSD-1.4). That said, I do think that the claims made
>by the documentation for securelevel 1 are false and should instead
>mention something about changing file flags through "conventional means"
>with a more complete briefing available for securelevel 2.
>Right. You will run in trouble if you try to umount /usr without
>'preparing' the system for it. To do this you also have to link UZip
>statically
>b/c libc is in /usr. This also means the other programs as syslogd etc.
>Some of them (getty) will die without explicitly kill them.
>Althought hard, it's not impossible and on my test system i was able to remove
>an immutable /usr/bin/login _without_ booting into single user (why the
>hell 'user'
>isn't it for root? :-) mode.
>
>Regardless whats written in the README, you have to define FORCE_OR_NOT to
>MNT_FORCE (not 1) if it should be done the 'umount -f' way, sorry.
There was an attachment with the "xploit", so if s'body wants, i can mail it.
Sighing off,
T@W
--============_-1280744880==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
--></style><title>buzz</title></head><body>
<div><font size="-3">I don't know if any of you has been following
Bugtraq lately but here are some recent posts (from Stealth &
Darren Reed) regarding (net)bsd.</font></div>
<div><font size="-3">I'm still too much of a new-bee to know if it
really touches our port, but here it is:</font></div>
<hr>
<div><font size="-3"><br></font></div>
<div><font size="-3">>'The design and implementation of the 4.4
BSD operating system'<br>
>page 263:<br>
><br>
>"... Security levels are defined as follows:<br>
>-1. [...]<br>
><br>
> 0. [...]<br>
><br>
> 1. Secure mode: The superuser-settable immutable and appned-only
flags<br>
> cannot be cleared; [...]<br>
><br>
> 2. [...]<br>
><br>
>"<br>
><br>
>That's not true. You can do it either with fsdb or with the
appended<br>
>exploitcode. Sorry for that fat mail, but the code is not upload
on my site<br>
>yet, but i guess you also will find it there soon...</font></div>
<div><font size="-3"><br>
>The README describes exactly why you can erase these flags in
level 1.<br>
>I already send it to some friends and we found it working at
least with<br>
>FreeBSD (3.1). I guess that this is a general problem. perhaps
someone<br>
>verifys this on other BSD's too.<br>
><br>
>Solution<br>
>--------<br>
><br>
>If fileflags are part of your security-concept, use security
level 2, not 1.<br>
>(sure, level 2 might also have been broken...)</font></div>
<hr>
<div><font size="-3"><br></font></div>
<div><font size="-3"><br></font></div>
<div><font size="-3">>I might add that to be able to unmount /usr,
if that is indeed where<br>
>/usr/bin/login is being run from, or any other filesystem for
that<br>
>matter, it needs to be totally unused. For this reason, I
think you<br>
>would be hard pressed to have /usr unmounted in a manner that
would<br>
>go undetected unless you were in single luser mode.
Depending on<br>
>what else runs on the system and how packages are installed,
the<br>
>same might be true for other file systems often used for
installation<br>
>of binaries (/usr/local). To give you some idea of the
programs which<br>
>would need to have been stopped before unmounting /usr are as
follows:<br>
><br>
>syslogd, update, cron, inetd, getty<br>
><br>
>(according to NetBSD-1.4). That said, I do think that the
claims made<br>
>by the documentation for securelevel 1 are false and should
instead<br>
>mention something about changing file flags through
"conventional means"<br>
>with a more complete briefing available for securelevel
2.</font></div>
<hr>
<div><font size="-3">>Right. You will run in trouble if you try to
umount /usr without<br>
>'preparing' the system for it. To do this you also have to link
UZip statically<br>
>b/c libc is in /usr. This also means the other programs as
syslogd etc.<br>
>Some of them (getty) will die without explicitly kill them.<br>
>Althought hard, it's not impossible and on my test system i was
able to remove<br>
>an immutable /usr/bin/login _without_ booting into single user
(why the hell 'user'<br>
>isn't it for root? :-) mode.<br>
><br>
>Regardless whats written in the README, you have to define
FORCE_OR_NOT to<br>
>MNT_FORCE (not 1) if it should be done the 'umount -f' way,
sorry.</font></div>
<hr>
<div><font size="-3">There was an attachment with the
"xploit", so if s'body wants, i can mail it.</font></div>
<div><br></div>
<div><font size="-3">Sighing off,</font></div>
<div><font size="-3">T@W</font></div>
</body>
</html>
--============_-1280744880==_ma============--