New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CVE-2020-8444: analysisd: OS_ReadMSG heap use-after-free with ossec-alert msgs. #1817
Comments
thinking about this more: I think this proposed fix would introduce a memory leak. Using The This is likely a case where someone more familiar with this codebase will have to suggest a better fix. |
|
This was assigned CVE-2020-8444 |
|
Is there any progress on this or some sort of ETA ? |
|
Bump as well. I don't see a fixing commit for this one but not sure if I overlooked something. |
The
ossec-analysisd'sOS_ReadMSGfunction callsOS_CleanMSGat the start of processing a received message from the ossec queue UNIX domain socket.In
src/analysisd/cleanevent.ctheOS_CleanMSGfunction populates thelfstruct, setting fields likelog,hostnameandprogram_nameto substrings of thelf->full_logbuffer.After cleaning any messages that meet the ossec-alert decoder's criteria are given to that decoder for further processing.
After processing an ossec alert msg from a client the ossec alert decoder will free the
lf->full_logpointer at the end of its processing, replacing it with a new pointer and populatinglf->generated_rule:ossec-hids/src/analysisd/decoders/plugins/ossecalert_decoder.c
Lines 184 to 191 in abb36d4
Though the
OSSECAlert_Decoder_Execfunction returnsNULLand not1further rule processing of thelfstruct occurs duringOS_ReadMSGbecause of thelf->generated_ruleset by the decoder before freeinglf->full_log.ossec-hids/src/analysisd/analysisd.c
Lines 872 to 879 in abb36d4
If any subsequent processing associated with the generated rule accesses the
lf->hostnameorlf->program_namefields set byOS_CleanMSGthey will be accessing memory of a freed heap chunk previously containing thelf->full_log.I believe the bug was introduced in fcca013 on July 23, 2008 and affects OSSEC v2.7+.
This is triggerable via an authenticated client through the
ossec-remoted. The client needs only write a ossecalert message that will have theprogram_nameorhostnameset duringOS_CleanMSG.I don't have a strong sense for the possibility of exploitation. I suspect this may be turned into an out of bounds read of heap memory accessing
program_nameorhostnameduring rule processing if the area pointed to after the syscheck decoder free isn't null terminated.One possible fix would be for the ossecalert decoder to
os_strdupthelf->hostnameandlf->program_namebefore freeingfull_log.The text was updated successfully, but these errors were encountered: