Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The Nginx DNS resolver is used to resolve hostnames via DNS for multiple parts of the popular reverse proxy. When validating the DNS address, there is an off by one heap overflow that could potentially lead to code execution. How is this done?

ngx_resolver_copy() function is used to validate and decompress each DNS domain in a DNS response. This is done in two steps:

1. The uncompressed domain name size is calculated. Once this occurs, the input packet is validated, discarding names containing more than 128 pointers.
2. An output buffer is allocated from the size calculated in the previous step. Then, the uncompressed name is copied into it.

In order to separate the resolved domains, a dot is used. The decompression step only believes that a dot can occur between labels. However, if the pointer for the domain is a pointer to NULL, then the dot is written past the end of the heap buffer.

If the size of the buffer happens to align with the heap size, this can be used to overwrite the metadata of the size of the heap chunk. 0x2E will clear the PREV_INUSE bit and set the IS_MMAPPED flag on the heap chunk. Because of the IS_MMAPPED, I would be surprised if this was possible to exploit by itself.

The end of the article mentions that this vulnerable function can be hit several times in the normal processing of a response, triggering multiple off-by-one writes. Additionally, with a poisoned CNAME, this could be used to cause an additional OOB write and OBO reads within the CNAME functionality.

Interesting finding in a high impact target. This was a simple logic assumption that was made about how the information was going to get sent back, even though the attacker does not have to conform to this.