Archive

Posts Tagged ‘64bit’

CVE-2010-3081: 64bit Linux Kernel Root Exploit

September 20th, 2010 1 comment

Well its been a heavy week on the security front, first up is a Linux root exploit for 64bit Machines.

A vulnerability in the 32-bit compatibility layer for 64-bit systems was reported. It is caused by insecure allocation of user space memory when translating system call inputs to 64-bit. A stack pointer underflow can occur when using the “compat_alloc_user_space” method with an arbitrary length input.

What does that mean? Essentially, some sanity checks in the compat_alloc_user_space function to check the length and ensure that the pointer to the block of memory is within the user-space of the process is valid was missing. The fix has already been committed but if you are running any x64 versions of Linux, make sure you update your Kernel – especially now that the exploit code is publicly available!

Read up on the exploit by Jeff Arnold from Ksplice and use this very useful CVE-2010-3081 high-profile exploit detection tool to determine if you’re boxens are already compromised.

Of particular note from his article is the breadth of exploitable distributions – see the references below for vendor specific information:

This vulnerability was introduced into the Linux kernel in April 2008, and so essentially every distribution is affected, including RHEL, CentOS, Debian, Ubuntu, Parallels Virtuozzo Containers, OpenVZ, CloudLinux, and SuSE, among others. A few vendors have released kernels that fix the vulnerability if you reboot, but other vendors, including Red Hat, are still working on releasing an updated kernel.

After downloading and running the tool under a non-sudo account, you should cheerfully get the following output.

thushan@dingo:~/tmp$ ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)

$$$ Kernel release: 2.6.32-23-server
!!! Not a RHEL kernel, will skip LSM method
$$$ Backdoor in LSM (1/3): not available.
$$$ Backdoor in timer_list_fops (2/3): checking...not present.
$$$ Backdoor in IDT (3/3): checking...not present.

Your system is free from the backdoors that would be left in memory by the published exploit for CVE-2010-3081.
thushan@dingo:~/tmp$

If not, its time to put those security drills into action!

References

{lang: 'en-GB'}
Share

.NET Framework 3.5 SP1 CLR Improvements

August 20th, 2008 No comments

Kevin Frie, the lead developer for core bits of the CLR just posted some information about the changes in .NET CLR 3.5 SP1. Heres an excerpt:

NGen infrastructure rewrite: the new infrastructure uses less memory, produces less fragmented NGen images with much better locality, and does so in dramatically less time.  What this means to you:  Installing or servicing an NGen image is much faster, and cold startup time of your NGen’ed code is better.

Framework Startup Performance Improvements: The framework is now better optimized for startup.  We’ve tweaked the framework to consider more scenarios for startup, and now layout both code & data in the framework’s NGen images more optimally.  What this means to you:  Even your JIT code starts faster!

Better OS citizenship: We’ve modified NGen to produce images that are ASLR capable, in an effort to decrease potential security attack surface area.  We’ve also started generating stacks that are always walkable using EBP-chaining for x86.  What this means to you:  Stack traces are more consistent, and NGen images aren’t as easily used to attack the system.

Better 32-bit code quality: The x86 JIT has dramatically improved inlining heuristics that result in generally better code quality, and, in particular, much lower “cost of abstraction”.  If you want to author a data type that only manipulates a single integer, you can wrap the thing in a struct, and expect similar performance to code that explicitly uses an integer.  There have also been some improvements to the ‘assertion propagation’ portion of the JIT, which means better null/range check elimination, as well as better constant propagation, and slight better ‘smarts’ in the JIT optimizer, overall.  What this means to you:  Your managed code should run slightly faster (and sometimes dramatically faster!).  Note to 64 bit junkies:  We’re working on getting x64 there, too.  The work just wasn’t quite there in time.

Whats interesting to note is that the CLR Optimisations for inlining will finally be coming to the 64bit CLR, just hope that it comes sometime sooner rather than later.

In the meantime, grab the .NET Framework 3.5 SP1.

{lang: 'en-GB'}
Share