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.
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.
I wanted to share a neat little trick I discovered while playing with gcc’s FORTIFY_SOURCE feature.
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.
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.