Skip to content
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

LLVM/Sys understanding checks output - sample concroob #17

Closed
marcinguy opened this issue Mar 18, 2021 · 1 comment
Closed

LLVM/Sys understanding checks output - sample concroob #17

marcinguy opened this issue Mar 18, 2021 · 1 comment

Comments

@marcinguy
Copy link

marcinguy commented Mar 18, 2021

Sounds like a great project. Would like to dig deeper into it.

Stack uninit bug
Name "serial_read_mp_array_73"
in 
Name "serial_read_mp_array"
path-to-file
[UnName 4,UnName 71]
If you inspect the serial_read_mp_array() function, the buggy block path is %4 (the first block) to %71,where we use [%73].

Can you elaborate with more words, maybe C equivalent of the code to see the bug.

I am new to LLVM and *.ll (LLVM IR) output seems kind of cryptic. Where can I learn more about to understand it? LL LLVM syntax (LLVM IR) ? Showing with your example would be a great help.

I run it on sample project (freetype2) and got results with concroob check i.e

Potential OOB index of
Right 4294967295
4294967295
Name "sfnt_get_var_ps_name_490"
is
path possible
in file
/tmp/freetype-2.10.3/objs/sfnt.ll
in function
Name "sfnt_get_var_ps_name"
on path
[UnName 1,UnName 135,UnName 288,UnName 289,UnName 306,UnName 319,UnName 457,UnName 458,UnName 459,UnName 466]

How to interpret it?

Below is the sfnt.ll for reference.

https://github.com/marcinguy/public/blob/master/sfnt.ll

@deian
Copy link
Member

deian commented Mar 18, 2021

You want to look at function sfnt_get_var_ps_name which in your file is on line 35217. And you want to look at basic blocks 1 -> 135 -> 288 -> ... The path is feasible but unless the tool spits out that the attack is possible it means you can reach that block but likely can't trigger the bug.

On LLVM -> C: You can take on #6 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants