While I agree with most of what you are saying (let's hope that 2021 will finally be "the year of memory-safe languages"), remote code execution issues also affect Java. https://securitylab.github.com/research/securing-the-fight-a... is just one of the latest prominent examples.
Yep, for sure. One of the things we see most frequently leading to code execution is still deserialization... but it's much more rare now, so a step forwards from my point of view.
With minor changes to the default exclude list for coverage instrumentation, you can use Jazzer to fuzz the Java standard library (at least the parts that are implemented in Java).
I've been interested in applying fuzzing to some projects I work on but every time I go to do this I'm not really sure where to start. Do you have any recommended sources to learn about how to use them in practice? :)
Thanks for the link, I wasn't aware of this new feature!
Our coverage instrumentation does not rely on JNI calls, only the libFuzzer callbacks do, so the overhead shouldn't be too substantial. It's certainly not a proper benchmark, but one core on my laptop can fuzz the more non-trivial examples at around 10,000 exec/s. We are also working on some further performance improvements.
I couldn’t find any information on what specific kinds of errors are recognized (except JNI memory handling), or how (mechanism) one specifies to the tool what constitutes an error. Can you shed some light on that, or give a pointer to relevant documentation?
By default, uncaught exceptions and memory issues in JNI libraries are reported as "crashes".
Additionally, Jazzer provides a hooking framework that can be used to implement domain-specific sanitizers for logic bugs. See https://blog.code-intelligence.com/engineering-jazzer#user-c... for an example.
Part of the reason for open-sourcing Jazzer has been to get the discussion started on what kind of "sanitizers" are needed to unlock the full potential of Java fuzzing.
If you want to fuzz a Java web app, our commercial platform CI Fuzz (of which Jazzer is one part) has built-in detectors for the typical vulnerabilities such as SQL injections: https://blog.code-intelligence.com/sql-fuzzing
> The trampoline first pushes an address pointing to the addr & 0xFFF-th entry in a "sled" of 0xFFF=4096 ASM ret instructions to the (native) stack and then performs a direct jump (also called a "tail call") to the sanitizer callback.
Great work Fabian! Nice to see this work becoming open source.
I am pretty new to fuzzing, please correct me if I am wrong: Since Jazzer fuzzes a Java application at runtime, can it be in principle also be used to fuzz a Java app without having it's source code?
Yes, that is exactly how it works, there is nothing that would require source code access.
If you have a Java app packaged as app.jar, all you need to do is write a fuzz target (with the fuzzerTestOneInput function) and package it into e.g. target.jar. Then you can run jazzer with
The new OpenSSH keys are very convenient if used correctly, but have a crucial disadvantage compared to the PIV-based approach of yubikey-agent: They currently can't be protected effectively with a PIN, so you should take good care of your security key or require multiple authentication methods on your server.
You can set a FIDO2 PIN on your security key and it will prevent ssh-keygen/ssh-add from regenerating the key files without it. But the relevant information (the key handle) can also be retrieved from the key in other ways that don't require the PIN. This is likely going to be fixed in a future version of OpenSSH, but may require a more recent kind of FIDO2 key. Until then, you should consider resident OpenSSH keys to provide only single-factor authentication ("possession"), even if a PIN is set on the security key.
The tokens are engineered to protect the private key material stored inside them very well, so you can be quite certain that nobody will ever be able to log in without physical access to the key (to touch/press the button).
However, the SSH protocol differs quite substantially from the FIDO2/WebAuthn spec in how it uses the PIN set on the token. Depending on how the SSH server is configured and which defaults your security token's manufacturer chose, it may be the case that the PIN is not needed to log in (assuming physical access to the token).
I hope that all of this will be clarified in the OpenSSH documentation at some point as it is quite vague about security guarantees at the moment. It's probably best to use the non-resident version of the new key type together with a passphrase on the key file for now, or rely on the PIV applet instead.
Oh huh, that's unfortunate. I was under the impression that the Yubikey would not sign anything without a PIN, period, and that it wipes its contents after three (ten?) wrong attempts. This greatly reduces the security of the token, and it's a shame since we were so close to perfect...
A Bloom filter with >500M items, even when allowing for a comparatively high rate of false positives such as 1 in 100, is still in the hundreds of MBs, which would not be that much more accessible than the actual dump files.
The compressed archive here is over 8 GB. An uncompressed 2 GB Bloom filter with 24 hash functions and half a billion entries has a false positive rate of less than 1 in 14 million.
75% space savings, with no decompression necessary for use, and a 1 in 14 million false positive rate is nothing to sneeze at.
Counting bloom filters are only marginally more difficult to implement. To increment a key, find the minimum value stored in all of the slots for the key, and then increment all of the stored values for that key that are equal to the minimum value. To read, return the minimum value for all of the values stored in slots for the key.
For these purposes, however, you probably instead want to store just separate Bloom filters for counts above different thresholds, since the common use case would be accept/reject decisions based upon a single threshold.
