ossec
CVE-2020-8444: analysisd: OS_ReadMSG heap use-after-free with ossec-alert msgs.
The ossec-analysisd's OS_ReadMSG function calls OS_CleanMSG at the start of processing a received message from the ossec queue UNIX domain socket.
In src/analysisd/cleanevent.c the OS_CleanMSG function populates the lf struct, setting fields like log, hostname and program_name to substrings of the lf->full_log buffer.
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_log pointer at the end of its processing, replacing it with a new pointer and populating lf->generated_rule:
https://github.com/ossec/ossec-hids/blob/abb36d4460b9f44ee90790d1138192bb01a2b21c/src/analysisd/decoders/plugins/ossecalert_decoder.c#L184-L191
Though the OSSECAlert_Decoder_Exec function returns NULL and not 1 further rule processing of the lf struct occurs during OS_ReadMSG because of the lf->generated_rule set by the decoder before freeing lf->full_log.
https://github.com/ossec/ossec-hids/blob/abb36d4460b9f44ee90790d1138192bb01a2b21c/src/analysisd/analysisd.c#L872-L879
If any subsequent processing associated with the generated rule accesses the lf->hostname or lf->program_name fields set by OS_CleanMSG they will be accessing memory of a freed heap chunk previously containing the lf->full_log.
I believe the bug was introduced in fcca01326255d66fa2b3f75357cda3780169c86d 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 the program_name or hostname set during OS_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_name or hostname during 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_strdup the lf->hostname and lf->program_name before freeing full_log.
One possible fix would be for the ossecalert decoder to os_strdup the lf->hostname and lf->program_name before freeing full_log.
thinking about this more: I think this proposed fix would introduce a memory leak. Using os_strdup will mean that the hostname and program_name pointers no longer point into the lf->log or lf->full_log buffer and will instead point to newly allocated memory.
The Free_Eventinfo function seems to be written with the assumption that freeing lf->full_log will free the program_name and hostname. Unlike other fields of the Eventinfo struct these two fields are not explicitly freed in the body of Free_Eventinfo.
This is likely a case where someone more familiar with this codebase will have to suggest a better fix.
Is there any progress on this or some sort of ETA ? Thanks in advance :) @atomicturtle
Bump as well. I don't see a fixing commit for this one but not sure if I overlooked something.
