[Features Request] Various Improvements

[VoidSec]

Hi, I've "compiled" a list of IMHO useful improvements for the plugin. I'd also like to offer my support in coding some of them (namely #1, #4 and #5) for which I'll try to make PRs in the upcoming days.

Quality of life:

• [x] #7
• [x] #8
• [x] Exclude from results items that have an empty "FoundIn" columns

Missing Rules:

• [x] #9

Windows Rules:

• [ ] Add "dangerous" Windows API/Windows-related vulnerabilities

PS: feel free to split them into specific issues we can address or rework any of those items. :)

[Martyx00]

HI, thanks for the list. I will look at ways to make #2 and #3 happen (#3 should be quick as well as #1). I am not sure how much time I will have left until end of this year so please be patient :)

[Martyx00]

Having second thoughts on no.3, this will prevent marking items that are called from piece of code that is not marked as function. This would be undesirable behavior when reversing bare metal firmware (which we do a lot) as it often happens that all functions are not marked as functions even though they are.

[Martyx00]

I have addressed no. 1 and no. 3 in the dev branch. Please use that for your PR with no.4 and no.5. There is still need for some fine tuning and adjsutments, I will merge to main once verything is ready. https://github.com/Accenture/VulFi/tree/v2_dev

[VoidSec]

Having second thoughts on no.3, this will prevent marking items that are called from piece of code that is not marked as function. This would be undesirable behavior when reversing bare metal firmware (which we do a lot) as it often happens that all functions are not marked as functions even though they are.

You're right it's better to have this type of information rather than completely losing it. Worst case scenario one can "hide" this case from the results after exporting them.

[VoidSec]

This (https://github.com/Accenture/VulFi/pull/9) fix the "Missing Rules: _stdio_common_vsprintf" task

[VoidSec]

For the Windows API/Windows-related vulnerabilities I'll need a bit more time as I'm quite busy atm

[Martyx00]

I will merger the branches to propagate changes so that those can be included in the new IDA plugin manager. Addition for the Win API calls will be included separately.

[VoidSec]

Sure, go ahead :D. I'm sorry but I didn't had the time to add that yet :(

[zhefox]

I'm looking forward to your idea of ​​Add "dangerous" Windows API/Windows-related vulnerabilities. At the same time, I want to know what progress it has currently. I think we can start with the high-risk functions of the Windwos api and some high-risk functions of the kernel.

[ascpwner]

Is it possible to add a method to get the number of bytes of the parameter that references the variable, e.g. pass in int [2] to get 8.

[ascpwner]

void vuln()
{
  char buf[16]; 

  return read(0, buf, 25uLL);
}

This simple code is obviously dangerous, but how do you get to the conclusion by the tool?

Is it possible to add a method to get the number of bytes of the parameter that references the variable, e.g. pass in int [2] to get 8.

[Martyx00]

This seems doable by using the lvar_t attribute width. You will however face false positives and false negatives when the type is not correctly derived or when the buffer is not defined in the current function as the plugin does not cross-reference data between functions.

[Martyx00]

Try using the latest commit: 779b4d9e3318940d9bc510c7e691024076a54717 It adds .size() which should return size of the variable in bytes. Be aware of all those cases that I have pointed out above (for your example code: param[1].size() < param[2].number_value()).