[Bug 578922] Re: mysql configuration should be adjusted to help prevent against chained attacks against LAMP stack

Jamie Strandboge jamie at ubuntu.com
Wed Nov 3 16:15:57 GMT 2010


** Description changed:

+ SRU Justification (apparmor)
+ 
+ 1. impact of the bug is medium for stable releases. While no
+ applications shipped in Ubuntu are directly affected by this, it would
+ be good if our LTS release provided a more secure user-tmp abstraction
+ for people deploying new profiles on Ubuntu 10.04 LTS.
+ 
+ 2. This has been addressed during the maverick development cycle.
+ 
+ 3. Patch is small. It places 'owner' in front of /tmp/** and /var/tmp/**
+ as well as requiring 'owner' for @{HOME}/tmp/ and its files and
+ subdirectories.
+ 
+ 4. TEST CASE:
+ $ cp /usr/share/example-content/Kubuntu_leaflet.jpg /tmp
+ $ sudo chown root:root /tmp/Kubuntu_leaflet.jpg
+ $ sudo aa-enforce /etc/apparmor.d/usr.bin.firefox
+ $ firefox /tmp/Kubuntu_leaflet.jpg
+ 
+ At this point, firefox will not display the image and something like the following should be in dmesg:
+ [ 1298.220693] type=1503 audit(1288797298.697:138): operation="open" pid=2948 parent=2944 profile="/usr/lib/firefox-3.6.12/firefox-*bin" requested_mask="::r" denied_mask="::r" fsuid=1000 ouid=0 name="/tmp/Kubuntu_leaflet.jpg"
+ 
+ 5. This will regress if a confined application tries to access files
+ owned by another user in /tmp (indeed, that is the protection we want ;)
+ and when someone confines two different applications that a) run under
+ differing user ids and b) interact with each other by one writing to
+ /tmp and the other reading that file from /tmp. I imagine that there are
+ very few users who would be affected by this. On the desktop, the evince
+ profile is affected at all by this change because it explicitly allows
+ read access to any files with an extension that it has support for.
+ Firefox's profile is disabled by default.
+ 
+ This is a change requiring the most testing and thought. I maintain it
+ is an important proactive fix for Lucid. It has been in maverick for
+ several months with no reported regressions once we decided on the right
+ approach. Once in -proposed, I plan to run the QRT tests on all AppArmor
+ confined applications in Lucid to verify no regressions.
+ 
+ 
  Binary package hint: apparmor
  
  I have reported this to the CERT/Bugtraq system so you may have been
  contacted by them.  It was a large bug report so something may have
  fallen though the cracks.
  
  The problem is AppArmor rule sets do not adequately protect a LAMP
  environment  from attacks.  Exploit code has been written which bypasses
  AppAmoror rule sets to obtain remote code execution.   The exploit can
  be obtained here (https://sitewat.ch/Exploits/nuke_exploit.txt).
  
  The attack scenario:
  Back before AppArmor it was common to see sql injection attacks against PHP/MySQL like this:
  Vulnerable code:
  <?php
  mysql_query("select name from user where id=".$_GET[id]);
  ?>
  Exploit:
  http://localhost/sql_inj.php?id=0 union select "<?php eval($_GET[e]);?>" into outfile "/var/www/backdoor.php"
  
  AppArmor stops this attack,  which is impressive.  However,  there is a
  flaw in this security system.  In my exploit i am dropping the file in
  "/tmp/theme.php"  then i use a Local File Include vulnerability (LFI) to
  execute this php file.   The problem is that BOTH MySQL and Apache have
  access to /tmp/.  The line "#include <abstractions/user-tmp>" in the
  usr.sbin.mysqld  is the source of the vulnerability.  The patch is very
  simple,  mysql should have its own tmp folder that only the mysqld
  process has access to.
  
  This whole concept of process separation to prevent attacks is
  completely undermined by creating "unions"  between processes in the
  form of these header files. In fact every time you see an #include in an
  app armor rule set,  its a point of weakness.    I hope to give a
  another killer blackhat/defcon talk,  this time i am talking about about
  my exploit and these abuses against apparmor.
  
  Thanks,
  Michael Brooks.

-- 
mysql configuration should be adjusted to help prevent against chained attacks against LAMP stack
https://bugs.launchpad.net/bugs/578922
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mysql-dfsg-5.1 in ubuntu.



More information about the Ubuntu-server-bugs mailing list