-
Notifications
You must be signed in to change notification settings - Fork 1k
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_ReadMSG
function callsOS_CleanMSG
at the start of processing a received message from the ossec queue UNIX domain socket.In
src/analysisd/cleanevent.c
theOS_CleanMSG
function populates thelf
struct, setting fields likelog
,hostname
andprogram_name
to substrings of thelf->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 populatinglf->generated_rule
:ossec-hids/src/analysisd/decoders/plugins/ossecalert_decoder.c
Lines 184 to 191 in abb36d4
Though the
OSSECAlert_Decoder_Exec
function returnsNULL
and not1
further rule processing of thelf
struct occurs duringOS_ReadMSG
because of thelf->generated_rule
set 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->hostname
orlf->program_name
fields set byOS_CleanMSG
they 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_name
orhostname
set 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_name
orhostname
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
thelf->hostname
andlf->program_name
before freeingfull_log
.The text was updated successfully, but these errors were encountered: