launchd Heap Corruption

2022.07.05
Risk: High
Local: No
Remote: Yes
CWE: CWE-189


CVSS Base Score: 10/10
Impact Subscore: 10/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: Complete
Integrity impact: Complete
Availability impact: Complete

launchd heap corruption due to incorrect rounding in launch_data_unpack (see issue 12 for background on launchd and launch_data_unpack) liblaunch.c: launch_data_unpack: ... case LAUNCH_DATA_STRING: tmpcnt = big2wire(r->string_len); if ((data_size - *data_offset) < (tmpcnt + 1)) { errno = EAGAIN; return NULL; } r->string = data + *data_offset; r->string_len = tmpcnt; *data_offset += ROUND_TO_64BIT_WORD_SIZE(tmpcnt + 1); break; case LAUNCH_DATA_OPAQUE: tmpcnt = big2wire(r->opaque_size); if ((data_size - *data_offset) < tmpcnt) { errno = EAGAIN; return NULL; } r->opaque = data + *data_offset; r->opaque_size = tmpcnt; *data_offset += ROUND_TO_64BIT_WORD_SIZE(tmpcnt); break; ... Both these cases check that there is enough space remaining in the buffer for the given payload size. However, they both then round up the given size to the nearest 8 bytes. This rounding can cause data_offset to become larger than data_size if the data_size was not a multiple of 8 bytes. This causes (data_size - *data_offset) to underflow, meaning that the code will continue to read and deserialize _launch_data structures off the end of the data buffer. Related CVE Numbers: CVE-2014-1359. Found by: Ian Beer


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top