Doyensec, an application security consultancy, publishes research on web, Electron, and eBPF security, fuzzing, and tooling.
HN commenters link it for technical security research, including ASN.1 fuzzing, Electron XSS-to-RCE issues, eBPF monitoring bypasses, and client-side CSRF.
This is a good write-up and I like the diagrams. What appears to still be notably missing from eBPF is an "off switch". AFAIK there are still no kernel boot time commands [0] to disable eBPF entirely. I have to recompile the kernel to disable it and it is known that most people will not do this.
eBPF has the potential for file-less malware to run hidden from detection and I foresee the ability to tickle ring -3 (and -4?) CPU within CPU functions while bypassing local firewalls.
Here is some example code of what people already know how to do today and this list will grow as people discover more capabilities. [1][2][3][4][5][6] These do require some privileges to insert but will remain running and hidden until reboot. Privilege escalation today is easier than ever with the growing misuse and poor configurations of sudo as well as the growing number of suid/setcap binaries. A common argument I get is "Well if someone ... then its game over". They are not entirely wrong, but I do not want yet another file-less anti-forensics vector that risks Linux being forbidden in secure zones nor do I want to play whack-a-mole using commercial tools like sysdig or complex tools people avoid like SELinux to try to fight this stuff.
[0] - https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
[1] - https://github.com/citronneur/pamspy
[2] - https://github.com/h3xduck/TripleCross
[3] - https://github.com/krisnova/boopkit
[4] -…
> but not TLS, X509, ASN1 etc (yet)
then this may interest you:
https://blog.doyensec.com/2020/05/14/asn1fuzz.html
^^ ASN1 is really the bees-knees for fuzzing telecoms protocols in UMTS/LTE/5G etc and doesn't get enough love in other domains. It's a high learning curve but once you get beyond the "standardese" language in the docs it's opening doors to opportunities in so many industries.
> BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One of the reasons for this could be that the bug count is proportional to the complexity/SLOC
the openSSL codebase is notorious but I think it's also because it has been in existing for so long. if I look around today I see 2 camps: cryptographers and software engineers. letting sw-engineers do crypto is usually a bad idea but it's often worse when cryptographers start coding. it's almost like a variation of the old joke of "the 2 most dangerous things in Tech are a sw-engineer with a soldering iron and a hw-engineer with a sw-patch" ... apart from complexity leading to bugs I'd also say there is another downside which is stronger in openssl: people end up using it wrongly which makes it a proverbial foot-gun for implenters.
> [1] https://github.com/guidovranken/cryptofuzz
very cool thanks!!
"Movie Hacker" should perhaps include nmap and sshnuke [1] despite being a real command and a real skiddie exploit [2]. When that that first played in the movies (The Matrix) people in the bay area theaters were standing up and cheering. People not familiar with the tools were very confused as to what was going on.
[1] - https://nmap.org/movies/
[2] - https://blog.doyensec.com/2025/03/04/exploitable-sshd.html
CSRF in modern web apps? It's still possible! Our latest research by Maxence Schmitt dives into using Client-Side Path Traversal to perform CSRF. Check out our latest blogpost and brand new Burp extension for finding bugs.
https://blog.doyensec.com/2024/07/02/cspt2csrf.html
Ah, yes, Electron, where a simple XSS can quickly turn into full account compromise and RCE? :O
https://blog.doyensec.com/2017/08/03/electron-framework-security.html