/var/log/messages
This section contains the latest news, announcements and thoughts from the MWR InfoSecurity team.
Full TextJust Arrived! - Max Pwnage
Jul 16, 2010
After much anticipation we are pleased to announce that the new Max Pwnage cards from MWR Labs are now available. The cards highlight the impact of a number of high profile security vulnerabilities that have affected systems and networks over the past 30 years. It has also been identified that the Max Pwnage cards can also be used to play an exciting game of skill and chance although this is purely a coincidence.
How do I get my hands on a set?
If you are an existing client of MWR InfoSecurity then speak to your contact within the company and they will be able to provide you with your own set. If you aren’t fortunate enough to already work with the company there are a number of ways you can get your hands on a set. Simply speak to an MWR consultant at one of the many public security conferences that they will be attending in the coming months. You will find consultants either attending or speaking at the following events:
- Black Hat Briefings – Caesars Palace Hotel and Casino, Las Vegas, Nevada, USA (July 28th, 29th 2010)
- Defcon 18 – Riviera Hotel and Casino, Las Vegas, Nevada, USA (July 30th – August 1st 2010)
- Sec-T Security Conference – Rio Theatre, Stockholm, Sweden (September 10th, 11th 2010)
- Making Sense of Risk (Invite Only) – Altitude 360, London, England (September 23rd 2010)
- T2 Security Conference – Radisson SAS Royal Hotel, Helsinki, Finland (October 28th, 29th 2010)
Further events will be announced in the near future so please keep checking the MWR Labs website for an opportunity to get your hands on these highly sought after cards.
Who is Max Pwnage?
Max is a shadowy character who is responsible for finding and exploiting vulnerabilities in computer systems. Keep your eyes open for him as he is always on the trail of emerging threats and issues that could affect the security of your computer or your business.
Palm webOS 1.4.5 fixes security issue found by MWR InfoSecurity
Jul 07, 2010
Palm has released version 1.4.5 of its mobile operating system, this release fixes an issue found by MWR InfoSecurity. Most mobile carriers have started to push the update to their customers. As soon as the majority of devices have been fixed we will release a detailed advisory on this issue.
The Palm release notes are available here:
http://kb.palm.com/wps/portal/kb/na/pre/p100eww/sprint/solutions/article/68919_en.html#145
Assessing the Tux Strength: Part 1 - Userspace Memory Protection
Jun 29, 2010
Introduction
This is a first of a series of articles describing different security mechanisms and exploitation mitigation techniques available in Linux environments and their use across various Linux distributions. This article focuses solely on userspace protections. Subsequent articles will focus on specific software such as web browsers or network daemons and their security exposure as well as additional kernel security mechanisms and frameworks that are available.
Memory corruption attacks are still a very common way to compromise a modern computer system. However, the once basic techniques of buffer overflows have evolved into more sophisticated memory corruption attacks and at the same time the mechanisms to protect the integrity of processes and system memory has also improved.
Probably every attack mitigation technique that has been developed over time to mitigate memory corruption exploits can be implemented and used in one form or another in a Linux operating system. Many people argue that some of the protection mechanisms are more effective than others, for example by mitigating against a larger number of different attacks. Furthermore, a number of them arguably have a performance impact on the system and could also produce some challenges in terms of compilation of the specific software as well as in ensuring compatibility with the rest of the system.
It is probably safe to say that these two factors (the impact on performance and the maintenance overhead) are the biggest obstacles to have all of these mechanisms implemented and enabled by default in any given Linux distribution. As with any complex software and development effort (particularly those that are open source), it comes with no surprise that it is possible to find some political or at least ideological issues at play as well (e.g. the wide ranging discussions between Grsecurity and the main kernel development teams). Therefore, as we will see within this document different distributions have different mechanisms and protection enabled by default. A comparison has been completed between the default stable releases of five popular Linux distributions - Debian, Fedora, Ubuntu, OpenSUSE and Gentoo Hardened relating to key protection mechanisms which can contribute to the overall security of the system. The author believes that the first four named distributions would be most prevalent across enterprise environments; Gentoo Hardened has been chosen as a comparison point, as this distribution aims to provide the user with the ability to have all of the considered security mechanism enforced system wide with relative ease, although with much greater time requirements due to the need of compilation of the software.
The exact versions of Linux distribution that have been assessed are as follows:
• Debian 5.0.4
• Fedora 13
• Gentoo - hardened stage 3 tarball and stable portage tree
• OpenSUSE 11.2
• Ubuntu 10.04
Stable x86 32-bit releases were used and all systems were tested within virtualised environments using KVM virtualisation. All systems were tested on an Intel processor with native support for the NX bit and virtualisation.
The following security mechanisms were considered:
• Non Executable memory mappings (use of the hardware NX bit)
• Position Independent Code/Executable (PIC/PIE)
• FORTIFY_SOURCE feature of modern glibc implementations
• Stack Smashing Protection (SSP) - also known as stack canaries
• RELRO - enables hardening of the ELF executable by reordering certain file sections and marking them read-only
The following tools have been used for comparison:
• checksec.sh - with a small modification to show status of FORTIFY_SOURCE.
• Custom python script that expanded on the ‘checksec.sh’ functionality
All sample data was taken with a user logged into an X session with a running sshd daemon and Mozilla Firefox browser. As the distributions varied in the number of processes that were started by default, in some case a single process had a bigger impact on the overall percentage score as for instance Ubuntu was by default running 96 processes versus 34 processes on Gentoo!
According to its Wikipedia entry, the Linux kernel has NX bit support since the 2.6.8 release in October 2004. It is enabled for both 32-bit and 64-bit kernels for hardware that has the NX bit. In order to take advantage of non-executable memory mappings on hardware that does not support the non-execute bit, it is necessary to use the grsecurity patch or alternatively the Exec Shield patch from Red Hat. It should also be noted, that without additional protections an attacker could easily bypass the NX bit for instance by manually adjusting the permissions that are set on a given memory page. Nevertheless, as this is a realm of the Linux kernel and will therefore be discussed in greater detail in future articles.
It should also be noted that apart from the NX bit support, all of the protection mechanisms discussed here are to be implemented in the userspace and not at the kernel level. It is important to acknowledge that a vulnerability within the Linux kernel could be exploited regardless of the protection mechanisms that are enabled for the user space processes. It is possible to compile modern kernel with Stack Smashing Support (SSP) (using the gcc -fstack-proctector option enabled in kernel configuration), although additional kernel security enhancements would often require applying external patches such as the grsecurity patch. Some distributions tend to maintain their own set of kernel patches that include some additional security features. Nevertheless, as mentioned earlier kernel security issues are excluded from this article and will be included in a future part.
A closer comparison of all of the five distributions revealed differences in approaches to security mechanisms that are enabled by default. The detailed results of the testing are presented and described below (all graphs are shown as a percentage of all running binaries).
RELRO
RELRO protects internal data structures of an ELF file from being used by an attacker to gain control of the execution flow. This is achieved by modifying the PLT (Procedure Linking Table) or GOT (Global Offset Table) sections of the ELF file. When full RELRO is used, the whole GOT is marked as read-only when the process is running and therefore cannot be modified by an attacker. For partial RELRO, only PLT-GOT is marked as read-only. Both options also reorder internal ELF data structures, such that internal structures precede other sections and as such are protected should an attacker be able to overflow other ELF sections. It should be noted that full RELRO requires all symbols to be resolved during the start-up of a binary (so the GOT can be marked as read only) and as such could result in a longer start-up time for big applications that would need to load large number of symbols for all shared libraries.
As can be noted from the diagram above, Debian and Fedora do not take full advantage of this mechanism, having it enabled in partial mode only for a small percentage of binaries. In our test case, Fedora and Debian did not support full RELRO for any of the binaries that were run by default. On the other hand, OpenSUSE and Ubuntu supported at least partial RELRO for all processes and full RELRO for small number of them (with Ubuntu reaching about 14% of all tested binaries). Gentoo Hardened had the full RELRO option enabled for all processes but one, which had partial RELRO enabled (Xorg). On the other hand, the only running binary in OpenSUSE during our test which had full RELRO enabled was pulseaudio. Given previous security issues in pulseaudio this is a good thing; however, it is worth noting that OpenSUSE does not use the setuid bit on this binary. The only binary on Debian that had partial RELRO support was the ‘dbus-daemon’ process.
Stack Canaries
Stack Smashing Protector makes it more difficult to exploit buffer overflow vulnerabilities by implementing additional security checks on the process stack. The SSP extension has been available in the GCC compiler since the 4.1 release.
As can be observed on the graph above, it is quite prevalent in Fedora, OpenSUSE and Ubuntu, with all of these distributions varying around 80% of all processes that have this feature enabled. Remarkable differences can be observed in Debian and Gentoo, where about 10% of checked processes have it enabled. In case of Gentoo Hardened this is due to internal issues which needed to be addressed before this functionality could be made available globally. This has been recently addressed and is currently available in a testing release of the gcc compiler and is expected to be moved into stable tree after a 30 days of testing period.
FORTIFY_SOURCE
The FORTIFY_SOURCE is a protection mechanism that attempts to prevent buffer overflows by replacing insecure functions with their secure equivalents as well as terminating execution of a process if an overflow has been detected. It should be noted that where buffer sizes cannot be determined during compilation or runtime, some exploits might be undetected by this mechanism. It also adds additional protections against format string vulnerabilities. More information about FORTIFY_SOURCE can be find here and here
It should be noted that the script used to assess the presence of the FORTIFY_SOURCE only checked if a symbol for an 'armoured' version of a function is present in a given binary. In theory, it is possible for a binary not to use any 'fortified' function, or a condition which cannot be fortified (unknown buffer sizes prior to execution) which could result in a false positive result. Also, if the sizes of all buffers are known before compilation, there is no need to use fortified function and as such it will not be replaced. This again could result in a false positive. For the FORTIFY_SOURCE option to be used, the binary needs to be compiled with the optimisation flag set to at least value of two. This is done by passing the '-O2' option to gcc during compilation.
As can be observed from the graph above, all compared distributions except for Debian make good use of this protection with the amount of enabled binaries reaching around 80% percent. Gentoo reaches around 90% which could indicate that other distributions could potentially enable it for few more binaries, although it should be appreciated that Gentoo runs far fewer processes by default than its counterparts. In this test, Debian had this feature enabled on two processes (3%) of all those that were tested, both of which belonged to the kerneloops package.
Position Independent Executables (PIE)
The ability to predict memory addresses of a process and its sections is a great aid for an attacker attempting to exploit a system. Although in recent years more memory randomisation support has been incorporated into operating systems, most of the binaries will still be loaded under the same address in any given Linux system. Unless they have been compiled as a Position Independent Executable (PIE) that is. Having a binary compiled as PIE allows the operating system to load and map all of the process sections at random addresses during runtime. This makes exploitation much more difficult provided that randomisation provides an acceptable level of entropy; a 64 bit system will be able to provide much better randomisation than a 32 bit system due to bigger address range available to the operating system.
All modern kernels have the ability to randomise certain memory segments of a process address space even if it has not been compiled as a position independent executable (PIE). This is controlled via the randomise_va_space setting in the proc filesytem. When set to 2, Linux will randomise stack, heap and mmap() requests, when set to 1, only stack space will be randomised. Nevertheless, as mentioned earlier, there could be a number of other memory sections of a process that would be mapped at the same memory addresses. Hence compilation of code as PIE/PIC allows the loader to run an entire binary from different memory regions each time, thus forcing an attacker to guess or bruteforce the correct memory mappings. It should be noted that Position Independent Code can have performance hit on x86 architectures, which is assessed by different sources to be usually between 1% and 5%. This can especially occur if a compiled binary needs to use non-PIC code using so called text relocation mechanism (TEXTREL). Moreover, some software, specifically if using machine specific assembly code, might refuse to compile as PIE all together.
As can be seen on the graph above, most of the compared distributions do not take advantage of this mechanism on the large scale. Values differ from 8% (Debian) to OpenSUSE (21%) while Gentoo Hardened achieves 100%. It should be noted that other distributions have this feature enabled for ‘high risk’ processes such as network enabled services like SSH. However, apart from Gentoo Hardened, only Ubuntu enables PIE by default for the Mozilla Firefox browser. Given the track record for vulnerabilities that have been discovered in a number of different browsers and attackers interest in them, one could expect that the binary is better armoured to withstand such attacks. Experience shows that the end user will very likely rely on and never change the default security measures that are enabled by a vendor. It would therefore be a good practice to embed in a rollout process of at least most critical binaries, an assessment of security measures that are enabled during package creation by distribution maintainers.
Conclusion
As has been discussed within this paper a number of effective and well tested security measures exist in a Linux environment; however, with minor exceptions they are not widely used or deployed by default. Also, different Linux vendors tend to have different approaches to using specific mechanism in their distribution. Although in some case more exposed binaries (like network daemons) have additional protection enabled (mostly PIE), others, like web browsers, mostly didn't. Where they were enabled, apart from instances mentioned earlier, it seemed that this was more of an accidental use or a mainstream developer decision rather than a consistent distribution policy.
As proved many times before there are no silver bullets to all security woes for Linux users. Different distributions will have different security mechanisms enabled by default and there seems to be no clear winner in this contest. While the Gentoo Hardened project can provide you with the highest use of the available userspace memory protection mechanisms, it is definitely not for faint hearted and you probably need to get your hands dirty to get the most of it. Maybe it is time to start asking your favourite distribution about their policy for security mechanisms described above?
The next article will focus on default and additional protections within the kernel itself which are enabled in the Linux distributions described above. This will be then followed by closer view on the practical side of exploitation of Mozilla Firefox and OpenSSH binaries running on different distributions with different protection mechanisms enabled.
CanSecWest 2010
Mar 30, 2010
Authors: Adam Bateman and Alex Plaskett
Vancouver, Canada.. Home to this year's winter Olympics but more importantly to CanSecWest 2010! Whether participating to present their latest research to the community or simply to observe, the three day security conference attracts highly respected security professionals from around the globe. The conference consists of a single track of presentations, varying from issues which have been discussed for many years previously to the cutting edge in security research.
This year's Pwn2Own contest challenged applicants to compromise a number of mobile devices and desktop web browsers for a chance to keep the target device as well as a cash prize. Nils from MWR InfoSecurity entered the contest armed with a zero day for the latest version of Firefox and won a Sony Vaio laptop running a fully patched version of Windows 7 using his exploit. Safari was claimed by Charlie Miller and Internet Explorer 8 by Peter Vreugdenhil with Google Chrome being the only browser left undefeated for the second year running. Out of the four mobile devices up for grabs Vincenzo Lozzo and Ralf Philipp Weinmann were the only contestants to submit and successfully exploit a vulnerability. This one was in Mobile Safari on the iPhone which allowed them to retrieve the phone's SMS database. The full details of the contest can be seen at: http://dvlabs.tippingpoint.com/blog/2010/02/15/pwn2own-2010.
In no particular order, below is a summary of some of the talks which stood out to us this year:
:: ShareREing is Caring Halvar Flake and Sebastian Porst, zynamics GmbH
ShareREing introduced the BinCrowd software used for collaborative sharing of reverse engineering information between team members. This software also provided a way to find and match functions which have been previously analysed by the BinCrowd in other software and thus reduce the amount of analysis a reverse engineer would need to repeat. This software was found to be especially useful because it could perform matching across code generated by different compilers. It seems very likely this software will be useful in future reverse engineering projects. More technical information can be found on the zynamics blog:
:: Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators
This talk consisted of discussing the techniques used to find a number of vulnerabilities in certain vendors' software. It discussed Charlie's methods for locating vulnerabilities (fuzzing) and analysis of the results. I found this talk interesting because there tends to be a lack of fuzzing results in the public domain, the methodology used to find the vulnerabilities and what metrics were used to determine the exploitability of them. The trends discussed throughout this presentation demonstrated significant differences between particular software and demonstrated where security had been incorporated into the product's development life cycle.
:: There's a party at ring0, and you're invited. - Julien Tinnes & Tavis Ormandy, Google
There's a party at ring0 talk covered a number of kernel level vulnerabilities used for privileged escalation on both the Windows and Linux platforms. My personal passion for low level technical details was satisfied and the talk was quite thought-provoking on the challenges faced in defensive kernel security. Although the vulnerabilities found here were very impressive it would have been interesting to expand on some of the vulnerabilities and explain the architecture of the kernel subsystems in greater detail. It's expected due to the large amount of vulnerabilities and variations in these that time constraints may have prevented this.
:: Practical Exploitation of Modern Wireless Devices - Thorsten Schroeder and Max Moser, Dreamlab Technologies
Despite the unfortunate technical difficulties which caused the projector to repeatedly cut out throughout the talk, Thorsten delivered a thought provoking presentation that was well received by the audience. Thorsten presented his research into the security issues related to wireless peripheral devices with a primary focus on wireless keyboards. He revealed the results of his analysis of the wireless protocol implemented by Microsoft and Logitech and the implementation of their Keykeriki V2 software which is capable of sniffing keystrokes in real-time as well as performing command injection. The presentation concluded with a demonstration of an attack which successfully executed commands and launched calc.exe on the target system followed by Thorsten stating that "range testing" revealed that the attack could be launched from an impressive 70 meters.
In summary, the high quality of a number of talks, the opportunities to discuss security issues with like-minded people and the motivation produced by the conference all provide a good reason to attend CanSecWest. It is expected that the research demonstrated at CanSecWest will provide a great benefit for the security community and help drive on further work both within MWR InfoSecurity and the industry at large.
Aurora and Web Browser Security
Jan 25, 2010
Germany's BSI (Federal Office for Information Security) recently warned web users not to use Microsoft Internet Explorer. The BSI advised users to switch to an alternative browser in the mean time until a patch was made available. Shortly after this release France's Certa agency also issued a similar warning to users.
What is the implication of these statements? It would seem like an 0day for an "alternative browser" has just substantially increased in value.
But even though these alternate browsers might be safer to use given the current threat, are they actually more secure? To reach a conclusion about whether this is actually the case it is necessary to look at the actual risk of successful exploitation, assuming such 0day exists somewhere. This assumes that entities or groups with sophisticated skills who are capable of writing exploits while sleeping and by-passing DEP at breakfast also exist (which is a fair assumption).
On a current Windows 7 system with fully updated browsers the following situation currently exists: -
| DEP/ASLR in browsers on Win 7 | |||||
| IE 8.0.7600.16385 | Firefox 3.6 | Opera 10.10 | Safari 4.0.4 | Chrome 3.0.195.38 | |
| DEP | Enabled | Enabled | Enabled | Enabled | Enabled |
| ASLR | No DLL without ASLR in default process |
Not properly used e.g. nspr4.dll |
Not properly used e.g. opera.exe |
Not properly used e.g. dnssd.dll |
Not properly used e.g. icudt38.dll |
We tested the default up-to-date installation of each browser in the table above on the Windows 7 Operating System. It should be noted that these results will vary substantially on different operating system versions. The actual ease of exploitation for these targets depends on a number of factors, for example, sandboxing techniques such as the Google Chrome Sandbox or IE 8's protected mode. Also, other weaknesses may allow DEP/ASLR to be bypassed such as the now patched Dowd/Sotirov technique. For the purposes of this assessment a measurement about the effectiveness of ASLR was obtained by observing the addresses of executable modules loaded in the default process.
Aside from the effort needed to produce a reliable exploit, another important factor in the risk exposed by the use of a particular browser is its market share. Internet Explorer is still is in the (un)fortunate situation of being the market leader, which makes it a juicy target for the bad guys.
In order to make web browsing safer, effective OS exploitation mitigations techniques and a fully updated browser are essential. Make sure you apply the Internet Explorer patch which was released on Thursday.
Update:
As of the 31th March 2010 the following updated browser versions still do not opt-in to ASLR properly:
Firefox 3.6.2, Chrome 4.1.249.1045 (42898) (now icudt42.dll), Opera 10.51 and Apple 4.0.5 (AppleVersions.dll).
The recent changes to Safari are notable, as AppleVersions.dll is the only binary left not opting-in to ASLR, hopefuly this will be fixed in the next release. We will continue monitoring the status of the browsers on a regular basis.