A simple trick to improve Firefox security

Firefox can run with add-ons disabled and what not, but if you run Firefox under Gentoo Linux, using the hardened profile, you can use a simple trick to have two different instances of Firefox available, with different enforcement of memory permissions and the usual PaX features:

PaX features disabled via PT_PAX_FLAGS, will allow most plugins to run without issues (although, for example acroread will require specific permissions on its own binary to run):

paxctl -pemrxs /usr/lib/mozilla-firefox/firefox-bin

Recommended settings (that might slow down Firefox in some systems, with noticeable overhead when there's a heavy use of Javascript or AJAX functionality):

paxctl -PEmRXs /usr/lib/mozilla-firefox/firefox-bin

For Acrobat Reader (only Address Space Layout Randomization -ASLR- can be enabled without affecting the functionality, blame the poorly compiled binary):

paxctl -pemRXs /opt/Acrobat7/Reader/intellinux/bin/acroread

You should try to use a different PDF application anyway, if you really trust any of them :)

Description of the PT_PAX_FLAGS flags:

PaX control v0.4
Copyright 2004,2005,2006 PaX Team 

usage: paxctl  

options:
      -p: disable PAGEEXEC            -P: enable PAGEEXEC
      -e: disable EMUTRMAP            -E: enable EMUTRMAP
      -m: disable MPROTECT            -M: enable MPROTECT
      -r: disable RANDMMAP            -R: enable RANDMMAP
      -x: disable RANDEXEC            -X: enable RANDEXEC
      -s: disable SEGMEXEC            -S: enable SEGMEXEC

      -v: view flags                  -z: restore default flags
      -q: suppress error messages     -Q: report flags in short format
      -c: convert PT_GNU_STACK into PT_PAX_FLAGS (see manpage!)
      -C: create PT_PAX_FLAGS (see manpage!)

Simply copy the firefox-bin binary to firefox-secure and apply the different flags as necessary.

Light over Ruby on Rails "critical security upgrade" 1.1.5

Yesterday, the core development team of the Ruby on Rails framework, announced in their weblog a critical security upgrade (1.1.5) which should be applied immediately.

*1.1.5* (August 8th, 2006)

* Mention in docs that config.frameworks doesn't work when getting Rails via Gems. #4857 [Alisdair McDiarmid]

* Change the scaffolding layout to use yield rather than @content_for_layout. [Marcel Molina Jr.]

* Includes critical security patch

Without giving details on the issue ("The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assalients") some people started reviewing the diff between the 1.1.5 and 1.1.4 releases, right away from the Subversion repository. A few hot spots have been indentified so far, one of them being a clear example of a potentially exploitable condition:


@@ -268,7 +273,7 @@
$LOAD_PATH.select do |base|

base = File.expand_path(base)

extended_root = File.expand_path(RAILS_ROOT)

- base[0, extended_root.length] == extended_root || base =~ %r{rails-[\d.]+/builtin}

+ base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) * '|'}/)

|| base =~ %r{rails-[\d.]+/builtin}

end

else

$LOAD_PATH


Some already have explained the issue (thanks Brandon for the links), although the development of a proof of concept by some Russian folks brought new issues to the attention of some RoR users. Basically, the fix introduced new problems, apparently.

The original issue was about the possibility of forcing Ruby to load arbitrary code after uploading a file and injecting a path to the LOAD_PATH variable through the HTTP_LOAD_PATH header (which is managed client-side... thus the user has control over it). The flaw in the routing code would allow this file (ex. a controller) to be loaded and executed. This would happen when requesting an URL with the controller name and one of it's methods, leadind the routing engine to walk through LOAD_PATH for the file and then executing it: http://railshost.tld/evil_controller/the_method.

Side-note: If $SAFE mode is enabled, at it's lowest level it's supposed to prevent code from being executed from world-writable directories, thus it shouldn't work from directories like /tmp. This probably doesn't apply to certain win32 installations anyways.

The newly discovered issues are related to loading built-in (already available) code through the autorouting engine, this causes different kinds of situations, from crashes to infinite recursion bugs (leading to the infamous 'Stack level too deep' error).

Nope, guys, the routing problems aren't fully fixed, and one still can require about 500 .rb files from standard Rails vendor/* directories just typing some text as URL in browser.

Apparently, a bug report ticket was submitted time ago:

Where is test code for that "patch"?

And there was already a ticket "#5408 Unhandled urls can cause loading of arbitrary ruby files" on Rails TRAC from 06/16 about mentioned issues...

Although, a follow-up comments that 1.1.5 upgrade fixes the situation for everything except Webrick:

The rails team is trying to contain damage. The fix works on everything except for webrick.

While the current status might have a lower immediate risk, controllers are expected to work all-together with other code, thus managing to execute methods within this controllers could still lead to exploitable conditions (ex. methods involved on filesystem-related operations) and such cases might be waiting for someone to take advantage of them.

Some light over the whole story comes with a new follow-up, explaining that actually, directories containing 'lib' will be used for the loading procedure, leading to an exploitable condition (but just a bit more complicated than the original one). This applies if HTTP_LOAD_PATH is still exposed and has direct influence over LOAD_PATH.

actionpack-1.12.4\lib\action_controller\routing.rb: 276

base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) * '|'}/) || base =~ %r{rails-[\d.]+/builtin}

base.match(/\A#{Regexp.escape(extended_root)}\/*(?:#{file_kinds(:lib) * '|'})/) || base =~ %r{rails-[\d.]+/builtin}

An user reported that it affected his Mongrel installation too (Maybe Webrick isn't the only one affected? and what about Lighttpd?).

Regular expressions can be are evil.

Another comment on the original announcement refers to the ticket number 3030 (nice one...), but right now the machine serving the RoR development Trac installation seems to be offline or failing to handle requests. Fortunately, Google cache entry exists.

[PATCH] method_missing exposes private and protected actions

I was recently trying to create a page that shows something other than the default "Unknown Action" message when a user calls an action that isn't defined in the controller. I used the method_missing method to do so which worked as advertised. However, I created an action declared as private in that same controller and the private action is available to anyone including via the web.

While some people might argue that this makes RoR not suitable for production, every so-called web application framework is affected by security flaws at some point (ex. now). Even those considered to be in a mature state of development. Some issues might be known, others might have gone wild.

Anyways, probably a 1.1.6 upgrade is coming soon. Hopefully next time everything will be documented properly, thus users won't have to figure out the problem by themselves, in order to decide if the fix is truly necessary.

The RoR team has already done a great job for bringing such a flexible and nice framework, not even mentioning the Ruby guys. Please, keep up the nice work ;-)

The other side of VirtualProtect() and friends: DEP evasion

As some people may think that the regression tests which involve VirtualProtect() usage for evading DEP, are wrongly implemented and present a legitimate feature as a potential risk, the images below show "hot spots" in the disassemble of Microsoft Windows Media Player and Skype. The first, as most multimedia applications in either GNU/Linux or Microsoft Windows, needs to generate code on run-time and this requires access to executable memory. Skype was known to break with Data Execution Prevention (DEP) enabled, until it was fixed...

Image below shows Skype allocating memory with PAGE_EXECUTE_RADWRITE access:

PAGE_EXECUTE_READWRITE 0x40

Enables execute, read, and write access to the committed region of pages.

Allocating memory with such a nice permission is for sure an easy way to get around DEP-related compatibility issues. Basically, DEP will be useless. If the memory area allocated, receives some-how user input (or at least is partially controlled by another process), code could be written and then executed without any barrier, including DEP protection.

19.01.2006 version 2.0.0.73

• bugfix: crashes when DEP is supported in hardware

Now let's look over Windows Media Player....

It doesn't matter if we allocate memory with RWX (Read-Write-Execute) access or we just allocate it with write access and then change it to be executable. In any case, if memory becomes executable after writing from user-input or similar unsafe sources, DEP will be unable to protect against it, as there's no enforcement in place for memory access permissions. You just have to rely on the vendor, and trust that they didn't go the easy way and didn't fix their code, but just applied a workaround.

For further information:

1. MSDN Memory Management functions: VirtualProtect()
2. MSDN Memory Management functions: VirtualAlloc()
3. MSDN Memory Protection Constants
4. Blog on Cyberterror: A DEP evasion technique
5. ZDnet blogs: Skype 2.0 looked like a virus
6. Skype change-log
7. Buffer Underruns, DEP, ASLR and improving the Exploitation Prevention Mechanisms (XPMs) on the Windows platform. By David Litchfield, NGSSoftware Insight Security Research (NISR).

Browser fun everyday

The people from the Metasploit project came up with a certainly nice idea: a blog-style publication for releasing web browser bugs and security flaws on a daily basis for one month. A rush of issues have been published, affecting a wide range of browsers, from Microsoft Internet Explorer to Safari. Just for the shake of mayhem and destruction, some issues will get published over here as well, discovered using either their tools (DOM-Hanoi, etc) or the under-going project for developing an easy to use QA and vulnerability assessment framework, QANUM (first show-case is out...).Today's one is a simple and not-really-useful NULL pointer dereference in the Macromedia Flash ActiveX component function LoadMovie():

a = new ActiveXObject('ShockwaveFlash.ShockwaveFlash');

try { a.LoadMovie(-1, "bogus.swf") } catch(e) { }

The bug is triggered by passing a non-zero value to the first parameter (which represents the layer for the loaded movie). Nothing really interesting, right? It seems already fixed in Flash 9 (finally after remaining in 8 for quite a bit of time), and it seems there was previous knowledge of the bug, two years ago. Nice timing.

Zero-day buzz and unpatched, even ancient security flaws

Michael Sutton on the 0day buzz. An interesting read about how old vulnerabilities can be a serious problem to lazy administrators, or for those who get distracted by the rush of so-called advisories and other linenoise. It's nothing new but it doesn't matter how many times you tell the monkey to stop throwing the banana peel to the floor. Monkeys only care on the banana itself.

The point is, that new vulnerabilities draw attention. The ones that scare me are the old ones, the ones that have been forgotten about. Targeted attacks require specific vulnerabilities but many, if not most attacks, choose not to discriminate. The attacker simply wants control of as many machines as possible to send spam, phish for credit card numbers, etc. In this case, any old vulnerability will do, so long as a multitude of machines remain unpatched.

HD already talked on similar stuff in the Metasploit Project blog, how old and relatively new web browser flaws are being used to spread malware (well, adware would be more appropriate).

This combination of automated fingerprinting followed by a targeted attack should serve as wake-up call to anyone who believes that a patched flaw is no longer a significant threat. The Java ByteVerifier bug used in this script was fixed in April of 2003, over three years ago, yet still works well enough to be a key component of this malware installer. The fact is that an advanced malware installer is capable of attacking almost any browser or operating system and still succeed against enough people to make money for the attacker.

The mandatory links to the news and references:

1. Why all the hype about 0day? Michael Sutton's Blog


2. Internet Drive-By Shootings from The Metasploit Project


3. Internet Drive-By Shootings in the Metasploit Project blog


4. Why all the hype about 0day? at Slashdot.org


5. WebAttacker Unseats WMF as Most Popular Exploit

Microsoft Windows Vista beta-2build 5384: ASLR testing

Only heap is randomized and it's just around 7 bits (some times reported 5, 4, none and at most 8 bits), DLL base randomization only takes place in boot time and it seems to be just incremental in most cases (and affects only core system libraries like kernel32.dll), thus likely predictable:

kernel32.dll: GetTickCount()
774A910E
[reboot]
774F910E
[reboot]
77B6910E


No VirtualProtect() restrictions exist, thus all tests of that category fail. With DEP policy set to OptOut, the basic memory permissions enforcement tests have all positive results.

Looking forward to test the stack randomization and other improvements in post-beta-2. Right now, the results show the effects of a weak implementation, the heap randomization is too low for being considered truly effective and the fact that DLL base randomization is performed on boot time doesn't help. Basically, this is the same as a Windows XP Service Pack 2 system with DEP policy set to OptOut and hardware support for the NX bit.

Vista Probe reports "No Randomization" for the DLL base test due to the way it's done. It expects the executable to perform runtime randomization of the base address, but this is obviously not the case. It will work fine for both stack and heap randomization, as well as EXE base randomization (if it can be enabled on third-party applications).

A new article by Michael Howard, but still no information available with an in-depth explanation of how ASLR is implemented in Vista:

• Windows Vista Security – A Bigger Picture

Microsoft Windows Vista: Measuring the security enhancements.

A few days ago, Michael Howard, a member of the Microsoft Security Engineering group, made available a short description of what's supposed to be Address Space Layout Randomization (ASLR) in Vista.

• Stacks and Heap are randomized (stack-randomization is on post-Beta 2)

• EXEs and DLLs shipping as part of the operating system are randomized

• All other EXEs and DLLs will need to explicitly opt-in via a new PE header flag; by default they will not be randomized. 'Note that DLLs marked for randomization, such as system DLLs, will be randomized in every process (regardless of whether other binaries in that process have opted-in or not.

http://blogs.msdn.com/michael_howard/archive/2006/06/06/619163.aspx

As an experiment, the enhancements were tested by using a modified version of the paxtest tool, originally developed by Peter Buser and used for testing the capabilities of PaX and other projects, as a regression test suite capable of guessing how many bits are currently being randomized in a concrete section of memory, for example one allocated in the heap; among other tests (ie. return-to-function, etc). While the tests are pretty simple, they provide unbiased proof of the strength or weakness of the implementation being examinated. The information disclosed by Michael, days before the above quoted article, commented on the "probability" of guessing the right address on exploitation time:

In the case of Windows Vista Beta 2, a DLL or EXE could be loaded into any of 256 locations, which means an attacker has a 1/256 chance of getting the address right. In short, this makes it harder for exploits to work correctly.

It's worth noting that no snake-oil is present. He points out that, actually, ASLR makes successful exploitation of memory corruption-related issues harder. And that's completely true. Although, we are missing something here. The point is how difficult exploitation will be. And definitely, the current approach implemented for Vista is, with no offense meant to anyone (and again, no bias here), useless.

For an application that suddenly dies as of an attack or repeated attempts of exploitation, ASLR is a good option. Although, if we look over applications that actually re-spawn child processes and the like, the lower the randomization is, the higher the probability of successful exploitation in less time. What applications behave in such a suicide way? Apache is a good example :)

A GUI, user-friendly regression test suite is in development, which will also properly test the "Security Enhancements in the CRT " introduced in Visual Studio 2005. It could be, to make an analogy, the IBM Stack Smashing Protector (aka ProPolice) for Windows-based systems.

Some references for further information:

1. Security Enhancements in the CRT
2. Saying Goodbye to an Old Friend
3. Security-Enhanced Versions of CRT Functions
4. Michael Howard's Web Log
5. Address Space Layout Randomization
6. Windows Vista Address Space Layout Randomization – What is Randomized?
7. Address Space Layout Randomization in Windows Vista

Smells like... snake-oil?

• Snake Oil Warning Signs: Encryption Software to Avoid
• Steganography snake-oil exposed
• Beware of Snake Oil
• Crypto-Gram Newsletter: Snake Oil
• PGP Desktop Wipe Free Space Flaw