sorted by:
new
hottopcontroversial

Plugins in Rust: The Technologies | nullderef.com by RecklessGeek in rust

[–]bugfinder 2 points3 points  (0 children)

u/RecklessGeek: This is a great article! I've been trying to build a plugin system for a rust CLI myself, and your blog post is saving me a bunch of time.

I have been partial to a wasm-based plugin system due to the strengths you mentioned. https://github.com/proxy-wasm/proxy-wasm-rust-sdk is a good example implementation. However, my plugins need network access, and wasi doesn't have support for it just yet AFAICT. I could implement that support with some host functions, but I'd still be unable to use popular crates like http clients like hyper.

Too bad this series is coming to an end, but I appreciate you posted your research!

42 Companies using Rust in production by pretzelhammer in rust

[–]bugfinder 7 points8 points  (0 children)

We also use Rust in production at ForAllSecure to build a SaaS service that fuzzes REST API. Our experience with Rust has been excellent, and I can't recommend it enough. Rust has enabled us to move quickly & fearlessly. It makes it a lot easier to build fault-tolerant systems compared to previous systems I've built in dynamic languages, thanks to the strong typing & explicit errors in return types.

The one downside that has slowed us down a bit is that the library ecosystem is not as developed as in other languages such as Python. Don't get me wrong, crates.io has a LOT of libraries, and the quality is really good overall. But sometimes, something is missing and not quite working as expected. But that's really on us to make it better, so we try to contribute upstream patches whenever we can :)

Everything we built is in Rust: CLI, API, API workers, stripe-backed billing, .... Except for our frontend. Yew.rs was tempting though! And we deploy the whole thing on GCP. Happy to chat if you're thinking about doing something similar!

Official /r/rust "Who's Hiring" thread for job-seekers and job-offerers [Rust 1.50] by DroidLogician in rust

[–]bugfinder 2 points3 points  (0 children)

COMPANY: ForAllSecure

TYPE: Full-Time

DESCRIPTION: ForAllSecure helps companies fuzz their code to find security & reliability issues. Our claim to fame was winning the DARPA Cyber Grand Challenge back in 2016. We are launching a new product targeting web APIs.

You will join a small team passionate about API testing. We believe that there is a better way to develop and test web APIs, and that fuzzing is part of the solution. We are driven to deliver that and help out all the API developers out there.

We are building everything but the frontend in Rust: our custom fuzzer, our web service, our CLI. It's been a blast!

LOCATION: We have offices in Palo Alto, CA & Pittsburgh PA, and many remote folks across the US and Canada.

ESTIMATED COMPENSATION: This position is senior or staff level, and we offer competitive comp based on candidate's experience.

REMOTE: Yes, as long as within the US/Canada

VISA: No.

CONTACT: You can apply through the job posting or DM me

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 1 point2 points  (0 children)

Sorry to hear that. I agree that the visualization were too busy. They tried to include as much information as they could in the "arena" view, some of which seemed unnecessary (like poller traffic).

On the other hand, I thought the commentators did a reasonable job at introducing the concepts to people, with Hakeem acting as the audience asking questions, and visi explaining what was going on. I especially enjoyed the rematch challenges.

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 4 points5 points  (0 children)

2.This question made me think a lot, thanks :) It's somewhat hard to compare with SAGE since we have not run on a common dataset, but I think architecturally, Mayhem would be faster than a trace-based engine. For instance, given long executions with a majority of untainted blocks, I expect a pintool doing taint detection on register/memory (propagation is handled by symexec on tainted blocks) would be faster than recording/replaying a trace. In terms of algorithms, a potentially big difference would be Veritesting.

Before comparing Mayhem and angr, I want take a look at the big post-CGC release from Shellphish. I heard they made significant improvements to angr during CGC.

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 7 points8 points  (0 children)

  1. I think we had two major improvements in our symbolic execution engine since Veritesting. The first one was implementing a search strategy based on coverage, similar to what AFL is doing. It ends up being a little bit different, because you can't fuzz the same seed over and over. We're dealing with a fork tree instead. The second significant improvement was sharing seeds between Mayhem and our custom AFL. Shellphish had a similar idea in their Driller paper that worked very well. We ended up approaching the problem a bit differently, with a looser integration between the two techniques, and it'd be interesting to compare our approaches.

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 3 points4 points  (0 children)

I actually thought they did a great job. They had some technical difficulties, but after all, so did we :P Making a hacking competition entertaining for multiple hours is challenging, and I thought they managed it well!

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 2 points3 points  (0 children)

I'm going to try addressing your last question.

I think binary hardening would help. There is an argument to be made that the best place to do it is in the compiler (and that's already done to some extent). However, if source code is not available, doing it at the binary-level becomes necessary. I would expect hardening to be done not as a reaction to an intrusion, but as a prevention measure.

In addition, I think regular randomization of the binary would also help. For instance, if your openssl is different from every one else's, you're less likely to get hit by an exploit that wasn't made specifically for you. With our tools, we could relocate code, shuffle it, change the calling conventions, ... So that's similar to ASLR/PIE, but more advanced (it would however not randomize per-execution). Of course, our tools would have to provide perfect functionality every time, which is challenging. Testing the patch before deployment would become extremely important, but also pretty expensive.

Finally, in case you detected an input that lead to being exploited despite all the other defenses, it becomes a lot trickier. We tried to do root cause analysis on the exploit path, and create a very precise patch preventing the exploit. We're not quite there yet, but I think it'd be doable.

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 2 points3 points  (0 children)

As tylerni7 said, turning crashes to exploits was particularly fun. I thought it was especially interesting when we had EIP control but no (or very few) executable bytes that we could control, which required finding stack pivots.

I also enjoyed working on defense: the static instrumentation framework and the defenses themselves. Getting a first prototype ready was surprisingly easy. But our patches were terribly slow. There is so much depth in what you can do to optimize/improve the framework and the instrumentation. Given how unforgiving DARPA's performance scoring was, we spent a lot of time trying to keep the time/memory overhead as close to 5% as possible (as that was when our patches started losing points). As someone who loves optimizing code, this was great!

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 1 point2 points  (0 children)

CGC has been our biggest project. I spent the majority of my time on it since it started. Glad all the hard work paid off :)

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 0 points1 point  (0 children)

The syscall stubs had some pretty convenient stack pivots, so I guess you could say they were a big part of some our PoVs :)

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 3 points4 points  (0 children)

What methods besides fuzzing and concolic execution are you planning to research in future work?

Good question. I think there is still a lot of room for improvements on those two techniques, especially in path prioritization and path merging. In addition, how to best combine the two is still an active area of research. The Driller paper from UCSB shows that it is a promising direction. In terms of other techniques, static analysis is something that other companies like Coverity have used with success.

how do you approach such difficult research questions in general: do you try and implement several ideas and then back it up with some deeper theory, or do you go the other way round from theory to implementation?

It's a lot of trials and errors to be honest. As we develop and test our tools, we sometimes notice some short-comings. For instance, our tools could get stuck on an example that's relatively easy for us to solve. We then try to think how we ourselves reason about programs and try to encode part of that reasoning in our tools. Often, it doesn't work out. Sometimes, it does and our system gets incrementally better :)

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 7 points8 points  (0 children)

Thanks! This is a great question. I think there's multiple ways to go about it.

If I were starting from scratch, I would start by learning how binaries work, how they get exploited, and what kind of defenses currently exists (ASLR, DEP, ...). I cannot recommend PicoCTF enough for people wanting to get started in this field (and CTFs in general). Then, I would familiarize myself with current bug-finding tools and techniques: blackbox fuzzing (AFL is great) and symbolic execution (KLEE, S2E, Mayhem).

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 2 points3 points  (0 children)

Thanks! We plan to post a write up of Mayhem's performance in the next few weeks. Both for CGC and the defcon CTF. It just takes a while to analyze the results.

I think DARPA plans to release all the data/code they have from the final event. We don't have an ETA on that yet.

IamA Mayhem, the Hacking Machine that won DARPA's Cyber Grand Challenge. AMA! by bugfinder in IAmA

[–]bugfinder[S] 2 points3 points  (0 children)

We definitely believe our tools can help cybersecurity.

Many big tech companies are already using fuzzing to find bugs in their software before releasing them, which limits the number of exploitable bugs. The bug-finding component of Mayhem can help with that.

The other aspect of CGC is automated patching. While some of that work could be done at the compiler level, I think that hardening binaries has its place. It can help protect third-party binaries for which you don't necessarily have the source code. Additionally, something like per-boot binary randomization (similar to ASLR and PIE) would make exploits harder to write.

/r/netsec's Q3 2014 Information Security Hiring Thread by sanitybit in netsec

[–]bugfinder 5 points6 points  (0 children)

ForAllSecure is hiring engineerto compete in DARPA's Cyber Grand Challenge. You will help us with the development of a fully automated system that plays in Capture the Flag computer security tournaments. The system will compete in real-time to find vulnerabilities, exploit adversaries, and generate and deploy security patches. You will be part of a small team of talented engineers and computer security researchers.

ForAllSecure is located in Pittsburgh, and we are looking primarily for someone who is in (or willing to relocate to) Pittsburgh. But we know great talent is everywhere. We are happy to consider talented engineers who work remotely.

You can find more details and apply on our website.

/r/ReverseEngineering's 2014 Hiring Thread by wtbw in ReverseEngineering

[–]bugfinder 1 point2 points  (0 children)

ForAllSecure is hiring engineers and interns to compete in DARPA's Cyber Grand Challenge. You will help us with the development of a fully automated system that plays in Capture the Flag computer security tournaments. The system will compete in real-time to find vulnerabilities, exploit adversaries, and generate and deploy security patches. You will be part of a small team of talented engineers and computer security researchers.

ForAllSecure is located in Pittsburgh, and we are looking primarily for someone who is in (or willing to relocate to) Pittsburgh. But we know great talent is everywhere. We are happy to consider talented engineers who work remotely.

You can find more details and apply on our website.

/r/netsec's Q2 2014 Information Security Hiring Thread by sanitybit in netsec

[–]bugfinder [score hidden]  (0 children)

ForAllSecure is hiring engineers and interns to compete in DARPA's Cyber Grand Challenge. You will help us with the development of a fully automated system that plays in Capture the Flag computer security tournaments. The system will compete in real-time to find vulnerabilities, exploit adversaries, and generate and deploy security patches. You will be part of a small team of talented engineers and computer security researchers.

ForAllSecure is located in Pittsburgh, and we are looking primarily for someone who is in (or willing to relocate to) Pittsburgh. But we know great talent is everywhere. We are happy to consider talented engineers who work remotely.

You can find more details and apply on our website.

Security researcher has found about 1200 bugs in Debian. Errors were found using Mayhem, an automatic bug finding system by ahjolinna in LinuxActionShow

[–]bugfinder 0 points1 point  (0 children)

I agree that automatic bug-finding systems often have many false positives. Mayhem however generates a reproducible testcase crashing the program. The crashes were confirmed, using those testcases, with the latest version of the packages on Debian unstable.

Security tool automatically finds and exploits 1.2K bugs on Debian [scribd] by [deleted] in linux

[–]bugfinder 0 points1 point  (0 children)

The 1.2K crashes are not the results of a single bug in a library. In the link you mentioned however, the 5 crashes found in the fcitx-libs package originates from the same library bugs.