The ossec-analysisd's OS_ReadMSG function calls OS_CleanMSG at the start of processing a message read 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 syscheck messages are given to the syscheck decoder for further processing.
After processing a syscheck msg from a client the syscheck decoder will free the lf->full_log pointer in two places. One place is if the message indicated a change in an existing tracked file:
In both cases the syscheck decoder replaces the existing lf->log and lf->full_log pointers with pointers to new messages after first freeing the old lf->full_log. Afterwards the DB_Search, and DecodeSyscheck functions return 1 to OS_ReadMSG.
Since the decoder returned 1, the OS_ReadMSG function will continue processing the event, it will not jump to CLMEM:
If any subsequent processing rules access the lf->hostname or lf->program_name fields set by OS_CleanMSG they will be accessing memory of a freed heap chunk previously containing lf->full_log.
I believe the bug was introduced in 8672fa0 on Nov 18, 2006 and affects OSSEC v2.7+.
This code path is triggerable via an authenticated client through the ossec-remoted. The client needs only write a valid syscheck 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 syscheck decoder to os_strdup the lf->hostname and lf->program_name before freeing full_log.
The text was updated successfully, but these errors were encountered:
The
ossec-analysisd'sOS_ReadMSGfunction callsOS_CleanMSGat the start of processing a message read 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 syscheck messages are given to the syscheck decoder for further processing.
After processing a syscheck msg from a client the syscheck decoder will free the
lf->full_logpointer in two places. One place is if the message indicated a change in an existing tracked file:ossec-hids/src/analysisd/decoders/syscheck.c
Lines 572 to 576 in 60cf8d2
Another place is if the message indicated a new file to track:
ossec-hids/src/analysisd/decoders/syscheck.c
Lines 601 to 604 in 60cf8d2
In both cases the syscheck decoder replaces the existing
lf->logandlf->full_logpointers with pointers to new messages after first freeing the oldlf->full_log. Afterwards theDB_Search, andDecodeSyscheckfunctions return 1 toOS_ReadMSG.Since the decoder returned 1, the
OS_ReadMSGfunction will continue processing the event, it will not jump toCLMEM:ossec-hids/src/analysisd/analysisd.c
Lines 762 to 765 in 60cf8d2
If any subsequent processing rules access the
lf->hostnameorlf->program_namefields set byOS_CleanMSGthey will be accessing memory of a freed heap chunk previously containinglf->full_log.I believe the bug was introduced in 8672fa0 on Nov 18, 2006 and affects OSSEC v2.7+.
This code path is triggerable via an authenticated client through the
ossec-remoted. The client needs only write a valid syscheck 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 syscheck decoder to
os_strdupthelf->hostnameandlf->program_namebefore freeingfull_log.The text was updated successfully, but these errors were encountered: