Double free - originally reported in chromium but is actually in embedded
copy of icu - able to be triggered on crafted content to icu, in the case
of chromium this could be via a crafted webpage or similar so not too
dissimilar to usual web handling issues - memory corruption -> code
execution (but within chromium sandbox in that case)
New NSS vulnerability (CVE-2021-43527) discussion [06:17]
Discovered by Tavis Ormandy at GPZ
NSS is a very old project, code in question has existed since 2003 and
been exploitable since at least 2012 when it was refactored
Does a direct memcpy of an attacker controlled amount of data into a
fixed size buffer without specifically checking whether the data is too
large - classic heap-based buffer overflow
Object on the heap also contains function pointer which then get called
so relatively easy to get control flow and code execution as a result
NSS was one of the first projects added to oss-fuzz (Google), Mozilla do
own fuzzing as well, extensive testsuite and uses ASAN for internal
builds
Existing fuzzing and unit tests had test cases which could reach this
code but failed to find it for a number of reasons:
Fuzz input is limited to 10k - but to overflow need at least 16,384
bytes so fuzzing couldn’t have caught this
Individual code paths fuzzed but not so much end-to-end systematic
testing - so nothing which would try generating say large inputs in
this case - does occur for other code-paths though
Existing metrics almalgate results from all fuzzers - so hard to tell
how well a piece of code has been fuzzed as it may have been using a
fuzzed which may never trigger relevant input to find bugs like this
Seemingly well tested, well fuzzed code is not enough - need to look
systematically and quantify how complete the coverage is not just in
terms of LOC or inputs used, but also boundary conditions etc