| 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 |
|
