Fuzzing.in Logo FUZZING.IN
Back to Blog
0 day analysis

CVE-2019-0626 analysis

Author Hardik Shah
March 27, 2019
3 min read
CVE-2019-0626 analysis
I have spent quite some time in debugging the CVE-2019-0626. i have debugged it first with unpatched version and then applied the patch and then tried to see what changes have been made to fix this issue. My setup was:
  1. A vm having vulnerable Windows 2012 server installation. it has DHCP server installed. i was using it for some other purpose but then this came in handy as i didn't need to do anything to configure the environment.
  2. A vm having windows 7, from where i used to run POC code. i have coded my own poc based up on analysis done by https://t.co/qc1ZClWiTd
I have done this analysis sometime back and planned to write a detailed post but i got busy with my other work and couldn't do it. malwaretech has then posted a nice article here: https://www.malwaretech.com/2019/03/analyzing-a-windows-dhcp-server-bug-cve-2019-0626.html this bug is in vendor specific tag which is identified as 0x2b or 43. the issue is that if you send two vendor specific tag, one with correct length and second tag which follows first tag but second tag length is way too more then actual data, then heap corruption occurs. vendor specific tag follow TLV structure. T = type = 0x2b L = length = length of data V = value = bytes of length L following are some of the screenshot i have taken during my analysis:
  1. first it allocated heap:
2. After that it calls the memcpy: if you notice here, r15 has the address of memory location where first tag data is saved and rcx has the length of first tag. then rcx is added to r15 i.e. r15 will contain the address of end of first data + 1 memory location. but as you can see in image one, total memory allocated is of 0xa bytes only. 3. program then calls memcpy and tries to copy data from second tag but since the memory is only of 0xa bytes and therefore we get the error (if page heap is enabled, you should be able to get this error in first try, otherwise you need to keep sending malicious packet multiple times): 4. in the fix they added check if calculated length is less then mentioned length then program terminates:   Thanks, Hardik    
Previous cve-2019-0626 debugging.
Next [winafl]Client library targets an incompatible API version and should be re-compiled

Related Posts