I'm suspicious of the effectiveness. Most people are doing symbolic execution to find bad pointer dereferences as bugs, whereas this tool is doing it to build the least constrained model and then checking the code against that same model. Wouldn't any code paths that are discovered as part of symbolic exploration and have out-of-bounds read/writes then be infered away as constraints, instead of bugs? Or being unable to detect memory corruption in the form of controlled pointer value overwrites, since you can't say that all pointer dereferences derived from your symbolic input are bugs that allow for attacked controlled memory corruption, because you don't have a concept of what inputs are under user control unlike most uses of Angr or other symbolic tainting tools. Is there a better list of the types of bug classes or heuristics that this is able to catch? Are there any numbers on the false positive/false negative rates against a dataset?
chc4 6 days ago [-]
Thinking about it more, a lot of bugs come around downstream of your initial function inputs, and you'd still be able to catch things like "heap allocation and then out of bounds read from that allocation with an offset derived from input" just fine since your least-constrained model only infers for the inputs. That probably covers a lot of the normal use-cases for Angr plus automatically harnessing inputs to reach that, which sounds pretty useful
thinkmoore 6 days ago [-]
Yes, that's a good way to think of it---we need to come up with a valid / reasonable context in which to explore the function at all, which will subsequently let us look for other bugs (like the divide by zero in the blog post).
shw1n 7 days ago [-]
I’d built an AI agent to accomplish this using Ghidra + GDB for dynamic analysis (tested it on crackmes)
It worked surprisingly well
Applied to YC with it, sadly no interview
Was later told by some accepted friends/VCs that our application was good, but without pedigree we needed traction to de-risk / get accepted :(
nicce 7 days ago [-]
I think AI is currently much poorer for this use case, if you want to generalize it. There is less assembly code training data available where existing bad coding patterns are matched to actual bug descriptions. Assembly is more verbose so they also take more context width from LLMs. False positive are the biggest pain in this area. With LLMs it is also surprisingly difficult to test the existence of vulnerability in general - often you give a hint about the possible issue with the prompt itself. If you do it in large scale, false positives are everywhere.
geenat 6 days ago [-]
If you think its good why wait on YC...just build it.
shw1n 6 days ago [-]
Pre-seed funding w/o a lengthy pitch process
Much harder to bootstrap part-time w/ dependents
peter_d_sherman 4 days ago [-]
>"How it works
Fundamentally, GREASE works quite similarly to UC-Crux, our tool for under-constrained symbolic execution of LLVM.
Essentially, GREASE analyzes each function in the target binary by running it on a slate of fully symbolic registers.
When errors occur (for example, if the program reads from uninitialized memory), GREASE uses heuristics to refine this initial symbolic precondition (e.g., by initializing some memory) and re-runs the target function. This process continues until GREASE finds a bug, or concludes that the function is safe under some reasonable precondition on its inputs. The blog post introducing UC-Crux [https://www.galois.com/articles/under-constrained-symbolic-e...] describes this algorithm in considerable detail."
Fascinating!
It's almost like the ability to run a given function inside of its own Virtual Machine / Virtual Environment and setting parameters/constraints for execution, that is, defining pre-conditions and post-conditions which determine successful (defined) or unsuccessful (undefined) behaviors!
Let me speculate that future programming languages -- might have abilities like this by default, that is, implicitly baked into them...
In short, I like the set of ideas espoused by this tool, and future compiler/language writers would do well to consider them when they write their future compilers/languages...
(Phrased another way, it would be like the ability to run any function of a program inside of its own custom Bochs [https://bochs.sourceforge.io/] environment, set pre and post constraints, run/test as many of these as needed, and return back to main program/environment reporting any constraint violations... or something like that...)
Anyway, an interesting set of ideas!
theturtletalks 6 days ago [-]
Would this have uncovered the XZ Utils scandal quicker?
TheAdamist 6 days ago [-]
No.
This is looking for coding bugs that allow unintentional behavior, not intentionally malicious code.
curtisszmania 6 days ago [-]
[dead]
mrbluecoat 6 days ago [-]
I've Got Chills, They're Multiplying
ITwork2019 6 days ago [-]
Grease is the time, is the place, is the motion
Rendered at 04:45:25 GMT+0000 (Coordinated Universal Time) with Vercel.
It worked surprisingly well
Applied to YC with it, sadly no interview
Was later told by some accepted friends/VCs that our application was good, but without pedigree we needed traction to de-risk / get accepted :(
Much harder to bootstrap part-time w/ dependents
Fundamentally, GREASE works quite similarly to UC-Crux, our tool for under-constrained symbolic execution of LLVM.
Essentially, GREASE analyzes each function in the target binary by running it on a slate of fully symbolic registers.
When errors occur (for example, if the program reads from uninitialized memory), GREASE uses heuristics to refine this initial symbolic precondition (e.g., by initializing some memory) and re-runs the target function. This process continues until GREASE finds a bug, or concludes that the function is safe under some reasonable precondition on its inputs. The blog post introducing UC-Crux [https://www.galois.com/articles/under-constrained-symbolic-e...] describes this algorithm in considerable detail."
Fascinating!
It's almost like the ability to run a given function inside of its own Virtual Machine / Virtual Environment and setting parameters/constraints for execution, that is, defining pre-conditions and post-conditions which determine successful (defined) or unsuccessful (undefined) behaviors!
Let me speculate that future programming languages -- might have abilities like this by default, that is, implicitly baked into them...
In short, I like the set of ideas espoused by this tool, and future compiler/language writers would do well to consider them when they write their future compilers/languages...
(Phrased another way, it would be like the ability to run any function of a program inside of its own custom Bochs [https://bochs.sourceforge.io/] environment, set pre and post constraints, run/test as many of these as needed, and return back to main program/environment reporting any constraint violations... or something like that...)
Anyway, an interesting set of ideas!
This is looking for coding bugs that allow unintentional behavior, not intentionally malicious code.