Adding support for vulnerability types other than pointer corruptions and status of printf leak bug injection

[jvijtiuk]

Hello,

in issue #3 it is mentioned that currently only pointer corruption bugs can be injected.

I'd like to add support for another bug class, and eventually add support for chaff bugs of that type.

Looking at the source, printf leaks seem to be at least partially implemented. However the code in lavaTool/include/MatchFinder.h is commented out, with a comment stating that read disclosures are currently disabled.

What is the current status of printf leaks? I've managed to build LAVA with the printf code enabled, replaced the function name "::printf" match with just "printf" in MatchFinder.h:148, and added printf_leak to bugtypes in lava.sh, but LAVA didn't inject any printf leak bugs into the toy example, and the inject logs have no entries for printf leaks, so I assume I must have missed something.

If you could share some suggestions on what bug class would be the best to start working on, that would be great.

Thanks!

[AndrewFasano]

Hi Juraj,

Sorry for the slow reply but I'm excited to hear that you're interested in adding support for this! Printf disclosures were added a few years back by one of our collaborators in 3dd56c23a01bca6df4972e2f12ef643586acb465 and, as we made significant changes to LAVA's architecture, we didn't maintain support for it.

To the best of my knowledge, there shouldn't be any major issues with getting that bugtype to work, beyond the part where I commented them out since I assumed they had broken in some minor way.

One thing to watch out for with the printf disclosures is that they have their own Attack Points (ATPs) as well as bug types. The attack points for these disclosures are any printf statements (these are places we could modify to leak information). The bug type describes how to actually modify the source and I think this is probably where things are going wrong for you. Specifically in tools/lavaODB/include/lava.hxx:359 there might need to be a PRINTF_LEAK = 0 line in the num_extra_duas definition. Once that's set, you'd hopefully see tools/fbi/src/find_bug_inj.cpp's attack_point_lval_usage function go into the AttackPoint::PRINTF_LEAK case but I'm guessing something is going wrong before there because otherwise I think you would've been seeing a crash due to the unset value in num_extra_duas.

In terms of bug classes to add support for, I think the printf disclosures are a good place to start. Two other ideas are:

• Adding an off-by-one allocation bugtype whereas calls to malloc would be (conditionally) one byte smaller than they normally would be. This would probably have a fairly low yield, at least by our current validation approach where we just trigger the bug and check if it crashes or not (as opposed to trying to fuzz it or something that might trigger the bug and then, later get the program to crash).
• Adding a two-dua based bugtype. Right now REL_WRITE bugs are a misnomer which use three DUAs and these have a very low yield because they only work when all three of the selected DUAs work. However, they're much harder to discover than PTR_ADD bugs which just use a single DUA. This is described in #17.

If you have any progress on this on a fork, I'd be happy to take a look and help you debug farther.

[jvijtiuk]

Hello Andrew,

thanks for the reply, I was occupied by some other things so this reply is somewhat late too. I have however managed to inject printf leaks.

The main issue was that the matcher was added only when LAVA was started in inject mode, so the ATP queries were never added. Adding the matcher for both query and inject mode fixed the issue. I've tested the changes on the toy example, and all 50 injected bugs are successfully validated.

I've managed to implement the off-by-one allocation bug type that you suggested. The implementation is available on this fork: https://github.com/jvijtiuk/lava on the malloc-off-by-one branch. The bugs are successfully injected into the toy example, however none are currently validated. The handler implementation should work with realloc and calloc without issues, but I haven't managed to write a working matcher that matches all three alloc functions yet.

I haven't looked into the two-dua based bug type yet, although I will hopefully start working on it soon.

If you have any suggestions for improvements please let me know. In addition, if you want to merge the malloc off-by-one code I can open a pull request.

[AndrewFasano]

That's great to hear! I'm glad you were able to get it working.

If you want to open pull requests for the printf fix and/or the off-by-one allocation, I'd be happy to accept. Thanks so much for helping make LAVA better :)