Skip to main content

Leveraging glibc in exploitation - Part 3: Defenses

In the previous blog post in this series, we examined the memory layout of a program at runtime on Linux and how glibc fits in with that model. In particular, we looked at the call stack, how it can be abused to leak information, and its relationship with ASLR. In this post, we will look at a purposely-vulnerable example program and its built-in defenses in preparation for hacking it.

Leveraging glibc in exploitation - Part 2: Fingerprinting glibc

In part one of this series, we examined the GNU C library and its relationship with a program and the operating system. We also reviewed tools and methods for figuring out important details such as glibc’s version and where it is loaded in a program’s memory at runtime. In this part, we will look at what is involved in locating glibc in memory by leveraging a program’s memory layout, and identifying glibc’s version based on code loaded in memory.

Leveraging glibc in exploitation - Part 1: What is glibc?

The GNU C Library (glibc) is an open-source implementation of the C standard library that is primarily found on Linux-based operating systems. It provides a powerful set of APIs that simplify interacting with operating systems, as well as functions and code for creating programs. From a hacker’s perspective, this functionality can be repurposed to extend an exploit’s capabilities and viability. In this series, we will explore leveraging glibc to exploit a vulnerable program on a x86 64-bit CPU.

From strings to riches: Finding a user-assisted LPE in the wild

Recently, @pwnsdx noticed that Blizzard’s application modifies macOS' list of trusted X.509 certificates. Many applications use this information to decide whether a website or networked service should be trusted. As a result, modifying it is generally a bad idea. While researching this behavior with @pwnsdx, I discovered a user-assisted local privilege escalation (UALPE) vulnerability in the installer. In this post, I would like to share how I discovered this issue, and outline some of the strategies that led me to it.

Compile time options in Go applications

Making software features and functionality configurable improves the quality of both the code base and the end product. This can aid in debugging, increase code maintainability, and make code more testable. Sometimes, however, you may not want configuration parameters to change after compilation. Many programming languages provide patterns for this. Let’s take a look at a simple pattern for compile time options in Go applications using build tags and the cmd/ project structure.

Decompiling .NET software on Windows via SSH

If you are anything like me, you may find Windows “challenging” to use. Its GUI tends to get in the way of just about everything. Running Windows in a hypervisor only accentuates this. The CLI tools appear to follow the same pattern. Microsoft is actively improving this, but I still prefer using git bash. So, what does this mean if we are stuck on Windows, and we need to automate some reverse engineering tasks?

Hello World

Hi! My name is Stephen. I am a Site Reliability Engineer with a background in QA and Release Engineering. My real passion is anything related to hardware and software security. Without a doubt, I am a n00b. Maybe even an eternal noob? In any case, I slapped together this little static website with Hugo and Azure (both of which are really neat tools you should take a look at!). My hope is that I get to share something useful with you.