Activity log for bug #578922

Date Who What changed Old value New value Message
2010-05-11 18:38:57 Todd Smith bug added bug
2010-05-12 05:55:48 Jamie Strandboge visibility private public
2010-05-12 05:56:33 Jamie Strandboge summary Bypass AppArmor ruleset of MySQL allows for remote code execution. user-tmp abstraction can be used in combined attack
2010-05-12 06:45:24 Jamie Strandboge summary user-tmp abstraction can be used in combined attack mysql configuration does not prevent against combined attacks against LAMP stack
2010-05-12 06:45:29 Jamie Strandboge apparmor (Ubuntu): status New Triaged
2010-05-12 06:45:57 Jamie Strandboge bug task added mysql-dfsg-5.1 (Ubuntu)
2010-05-12 06:46:21 Jamie Strandboge mysql-dfsg-5.1 (Ubuntu): status New Triaged
2010-05-12 09:32:02 Jamie Strandboge apparmor (Ubuntu): status Triaged Fix Committed
2010-05-12 09:32:48 Jamie Strandboge description 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 antiquity 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. 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.
2010-05-12 09:42:54 Jamie Strandboge summary mysql configuration does not prevent against combined attacks against LAMP stack mysql configuration should be adjusted to help prevent against chained attacks against LAMP stack
2010-06-05 00:12:14 Kees Cook apparmor (Ubuntu): importance Undecided Medium
2010-06-05 00:12:15 Kees Cook mysql-dfsg-5.1 (Ubuntu): importance Undecided Medium
2010-06-05 00:12:23 Kees Cook apparmor (Ubuntu): assignee Jamie Strandboge (jdstrand)
2010-08-06 00:05:10 Launchpad Janitor apparmor (Ubuntu): status Fix Committed Fix Released
2010-08-06 01:15:44 Launchpad Janitor branch linked lp:ubuntu/apparmor
2010-08-16 12:33:20 Jamie Strandboge mysql-dfsg-5.1 (Ubuntu): status Triaged Won't Fix
2010-11-02 22:57:37 Jamie Strandboge nominated for series Ubuntu Lucid
2010-11-02 22:57:37 Jamie Strandboge bug task added apparmor (Ubuntu Lucid)
2010-11-02 22:57:37 Jamie Strandboge bug task added mysql-dfsg-5.1 (Ubuntu Lucid)
2010-11-02 22:57:50 Jamie Strandboge mysql-dfsg-5.1 (Ubuntu Lucid): status New Won't Fix
2010-11-02 22:57:59 Jamie Strandboge apparmor (Ubuntu Lucid): status New In Progress
2010-11-02 22:57:59 Jamie Strandboge apparmor (Ubuntu Lucid): assignee Jamie Strandboge (jdstrand)
2010-11-02 23:04:04 Jamie Strandboge apparmor (Ubuntu Lucid): importance Undecided Medium
2010-11-02 23:04:24 Jamie Strandboge apparmor (Ubuntu Lucid): milestone lucid-updates
2010-11-03 15:21:02 Jamie Strandboge bug added subscriber Ubuntu Stable Release Updates Team
2010-11-03 15:21:19 Jamie Strandboge bug added subscriber SRU Verification
2010-11-03 16:15:57 Jamie Strandboge description 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. 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.
2010-12-03 17:17:33 Martin Pitt apparmor (Ubuntu Lucid): status In Progress Fix Committed
2010-12-03 17:17:41 Martin Pitt tags verification-needed
2010-12-14 20:50:08 Martin Pitt tags verification-needed verification-donee
2010-12-14 20:50:14 Martin Pitt tags verification-donee verification-done
2010-12-15 11:50:58 Launchpad Janitor apparmor (Ubuntu Lucid): status Fix Committed Fix Released
2011-09-19 21:19:45 Ubuntu Foundations Team Bug Bot tags verification-done testcase verification-done