It's Bugs All the Way Down

Security Research by Dan Rosenberg

Breaking LibTIFF

  June 29th, 2010

In this post I’ll be providing details on a vulnerability I discovered in libtiff, which was recently made public with CVE-2010-2067. libtiff is linked into a wide range of applications, including browsers, document viewers, file browsers, and image software, and it might even be possible to leverage this bug to achieve code execution on embedded devices.

Read the rest of this entry »

Integer overflow in ld.so (CVE-2010-0830)

  May 2nd, 2010

A month or so ago, I reported an integer overflow vulnerability in ld.so (the linker/loader included with glibc) that could be exploited to achieve arbitrary code execution. The catch is, the vulnerability is triggered in the processing of a maliciously crafted ELF binary, so the actual potential for exploitation in real life is minimal. In many cases, invoking ld.so on an untrusted binary results in the execution of that binary, so in practice this should never be done. However, there are some options that can be used with ld.so that should not result in code execution, such as the case where a user invokes ld.so to verify the dynamic dependencies of an unknown binary, for example with the “–verify” flag.

Read the rest of this entry »

Fun with FORTIFY_SOURCE

  April 27th, 2010

I wanted to share a neat little trick I discovered while playing with gcc’s FORTIFY_SOURCE feature.

Read the rest of this entry »

Controlling uninitialized memory with LD_PRELOAD

  April 8th, 2010

In this post, I’ll be describing a technique that allows a local Linux user to exercise a degree of control over uninitialized memory on the stack when executing a program.

Read the rest of this entry »

Exploiting nano

  March 27th, 2010

A number of standard Linux utilities have been documented as being unsafe to run as root on untrusted input, from a security standpoint. For example, the ldd utility, designed to enumerate the dynamic library dependencies of executables, has documented behavior that may result in execution of arbitrary code when run on untrusted binaries [1]. The popular text editor, nano, is another example of a program that is unsafe to run as root on untrusted input. I hope to demonstrate that many of the assumptions users make in regards to security no longer apply in the scenario of running as root in a hostile environment.

Read the rest of this entry »

Newer Entries »