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.
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).
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.
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
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.
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 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.
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 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.
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.
I have recently added YubiKey/OpenPGP card support to the official ChromeOS SSH app Secure Shell.
While key generation is not yet supported, using an already set up Yubikey for SSH authentication on a Chromebook should be entirely pain-free: https://chromium.googlesource.com/apps/libapps/+/HEAD/nassh/...