Remotely Exploitable Flaws Patched in DHCP (remote code execution flaw included)

[LASER_oneXM]

Updates released by the Internet Systems Consortium (ISC) for the Dynamic Host Configuration Protocol (DHCP) software patch two remotely exploitable vulnerabilities discovered by a researcher at Google.

Felix Wilhelm of the Google Security Team found that the DHCP Client (dhclient), which provides a means for configuring network interfaces, is affected by a buffer overflow vulnerability that allows a malicious server to cause the client to crash.

In some cases, exploitation of the flaw could also lead to remote code execution, ISC said in an advisory. The security hole is tracked as CVE-2018-5732 and rated high severity.

“Where they are present, operating system mitigation strategies such as address space layout randomization (ASLR) should make it difficult to leverage this vulnerability to achieve remote code execution but we can not rule it out as impossible. The safest course is to patch dhclient so that the buffer overflow cannot occur,” ISC said.

 

[Deleted member 65228]

Address Space Layout Randomisation (ASLR) helps make exploitation a bit more difficult because addresses for routines in-memory (either exposed by a freely accessible interface or not - e.g. DLL exports) will be different each session. This means that the address of routine X on an attackers test environment will highly unlikely be identical for the same routine's address on a victims machine.

However, ASLR is easily defeated as long as you have access to the process' memory. You can make a signature (e.g. byte signature) and scan memory of the targeted process using the signature, and use that to locate the address of the target address. If the code for the routine searched for using the signature changes in the future then the pattern matching scan to find the routine's address can break, which is why wildcards can be very handy - wildcards are ignored if implemented into the pattern matching algorithm, allowing you to wild-card bytes which are part of code which is likely to change in the future.

NtQueryVirtualMemory is quite handy with these tasks, then you can remotely read memory with NtReadVirtualMemory (if the scanning has to take place remotely). Of course this would only be that useful if code was executed locally outside of the context of the exploited process prior to exploitation though. Otherwise you could just find the base address of the process in which your code is executing under from the Process Environment Block (Ldr -> linked list -> the first in-memory order list item will be the executable itself) and start your memory scanning there.

These memory scanning techniques are used for all sorts, including even AV engine development (of course it'd be a lot more thorough for that though).