Insinuator
insinuator.net · Group blog · on HN since 2012
The security research team at ERNW publishes technical write-ups of vulnerabilities in Bluetooth, Android, Xen, Rails, and other software.
What HN saysHN links it for vulnerability disclosures, including the Airoha Bluetooth headphone bugs, whose researcher posted the blog and white paper in comments, and RedStar OS watermarking.
45HN people shared it
19linked it in comments
37stories submitted
895story points
5 months agolast shared
2012people per year2026
Most-shared posts
- 1Analysis of Rails XML Parameter Parsing Vulnerability7 people · 81 points · first shared 2013 · 2 comments on HN
- 2RedStar OS Watermarking4 people · 64 points · first shared 2015 · 4 comments on HN
- 3CVEs in Bluetooth Headphones and Earbuds4 people · 15 points · first shared 2025 · 2 comments on HN
- 4Critical Bluetooth vulnerability in Android3 people · 504 points · first shared 2020 · 300 comments on HN
- 5Bluetooth Headphone Jacking: Full Disclosure of Airoha Race Vulnerabilities3 people · 1 points · first shared 2025 · discussion on HN
- 6An Android 8.0-9.0 Bluetooth Zero-Click RCE2 people · 139 points · first shared 2020 · 61 comments on HN
- 7What Can Happen in the Course of Vulnerability Disclosure2 people · 38 points · first shared 2015 · 6 comments on HN
- 8Xen XSA 155: Double fetches in paravirtualized devices2 people · 11 points · first shared 2015 · 1 comments on HN
- 9Of Corona, Buggy Audio Drivers and Industrial Espionage2 people · 7 points · first shared 2021 · discussion on HN
- 10Revisiting Xen’s X86 Emulation: Xen XSA 1232 people · 1 points · first shared 2015 · discussion on HN
- 11The Beauty of IPv6 Link-Local Addressing. Not1 people · 3 points · first shared 2016 · discussion on HN
- 12Ss7MAPer – A SS7 pen testing toolkit1 people · 3 points · first shared 2016 · 1 comments on HN
- 13When Your Edge Browser Syncs Private Data to Your Employer1 people · 3 points · first shared 2025 · discussion on HN
- 14Vulnerability Disclosure: Stealing Emails via Firefox's AI Features1 people · 3 points · first shared 2026 · discussion on HN
- 15Considerations on DMZ Design in 2016, Part 11 people · 2 points · first shared 2016 · discussion on HN
What HN people wrote when they linked it
kiliancs · 2015-09-11
Followup: http://www.insinuator.net/2015/09/sending-mixed-signals-what-can-happe…
jakobdabo · 2026-01-01
This is a good article: https://insinuator.net/2025/12/bluetooth-headphone-jacking-full-disclo…
willnix · 2026-01-01
One of the researchers here.
Many people seem to prefer text to videos, which I sympathize with.
So please excuse me hijacking the top comment with links to our blog post and white paper:
Blog:
https://insinuator.net/2025/12/bluetooth-headphone-jacking-full-disclo…
Paper:
https://ernw.de/en/publications.html
omeid2 · 2024-06-10
For the uninitiated: https://insinuator.net/2015/07/redstar-os-watermarking/
ben_w · 2020-11-08
North Korea is rather a lot worse: https://insinuator.net/2015/07/redstar-os-watermarking/
gruez · 2020-04-26
Exploit details were released a few days ago[1]. Some essential bits were removed, so not any script kiddie can use it, but it's only a matter of time before a full exploit available publicly.
As for how it relates to the app, I don't think it matters much. I'd imagine most people already have bluetooth enabled, so using this app or not won't change their vulnerability status.
[1] https://insinuator.net/2020/04/cve-2020-0022-an-android-8-0-9-0-blueto…
craftyguy · 2020-02-23
That's absolutely not true, e.g.:
https://insinuator.net/2020/02/critical-bluetooth-vulnerability-in-and…
There was another one regarding the wifi chip used in many popular phones a few months ago.
e12e · 2020-02-07
> Which priviliges is that? Can it access user data? Snoop on input/output?
This is somewhat addressed in a comment/reply by jorge:
https://insinuator.net/2020/02/critical-bluetooth-vulnerability-in-and…
> Hi, the Bluetooth daemon is a process on the Android system that runs in the background (daemon) that is responsible for managing the Bluetooth controller and handling of various Bluetooth related protocols, such as HCI, L2CAP and GATT. As it has to process attacker-controlled input it is susceptible to attacks. In addition, it has to run with high privileges (not as ‘root’ like on Linux) to support features like:
– file transfer => read files
– share Internet connection => configure network and VPN
– Human Interaction Devices => emulate keyboard and mouse
lightbyte · 2018-08-02
>Clustering is built into it with security
Just to note, distributed erlang is NOT secure AT ALL. You absolutely need your own source of network isolation to keep it secure.
By default the EPMD daemon (that coordinates nodes in a cluster) listens on an open port and accepts node join requests if they contain a correct secret cookie (short authentication string). EPMD has zero protection against brute force attempts to guess a cookie. If your EPMD port is open to the internet it is trivial to gain access to your entire cluster and execute arbitrary code.
See: https://insinuator.net/2017/10/erlang-distribution-rce-and-a-cookie-br…
cnvogel · 2017-01-05
Sintendo · 2016-12-15
I thought so too at first, but I'd expect non-x86 host systems running x86 guests to be vulnerable if that were the case. The advisory seems to indicate otherwise.
Anyway, I've done some digging and found an explanation here: https://insinuator.net/2015/02/the-dangers-of-x86-emulation-xen-xsa-11…
tl;dr: it falls back to emulation for very specific cases that cannot be handled by hardware-assisted virtualization
dang · 2016-03-10
We changed the url from https://www.insinuator.net/2016/03/docker-devops-security/, which points to this and doesn't seem to have any content of its own.
fwilhelm · 2015-03-10
I wrote a blogpost with some more details about the bug, which you can find here: http://www.insinuator.net/2015/03/xen-xsa-123/
zzzeek · 2013-02-01
Parsing is not deserialization. I keep having to say this on all these threads. There should be a giant glowing force field between these two practices.
the particular issue in the Yaml parser is explained pretty well here: http://www.insinuator.net/2013/01/rails-yaml/
jhart3333 · 2013-01-10
Not sure this is correct. I just skimmed the article.
http://www.insinuator.net/2013/01/rails-yaml/
From the comments:
"From what i’ve see here is that versions below 2.0 should not be affected by this issue as they do not support xml parameters and don’t have any XMLMini implementations."
cmpb · 2013-01-09
It's not a full-on answer, but it should clear up a little bit about how this vulnerability is possible.
http://www.insinuator.net/2013/01/rails-yaml/
xentronium · 2013-01-08
http://www.insinuator.net/2013/01/rails-yaml/
Some explanation why YAML user input is evil.
It works like this
1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML
"1 --"
It looks like string, but it's not.
1.9.3p327 :002 > Keyword.where(:id => id).first
Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LIMIT 1
reginaldo · 2013-02-20
The impact varies with the platform and parser being used, and with the extensions installed. I don't know the specifics of ExpatParser (the one used by Django), but in general, the "careless" parsing of unsanitized user-supplied XML might lead to:
- DoS
- Disclosing of sensitive files (in general, the XML has to "validate". In PHP, it's always possible to read any file accessible by the process parsing the XML).
- Making arbitrary network connections (with this an attacker can portscan a network, attack vulnerable services that would be protected by firewall, and/or use the vulnerable server as a restricted kind of proxy).
- Probing LDAP directories.
- Remote code execution.
See, for instance:
http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_12_Polyako…
http://defcon.org.ua/data/2/2_Vorontsov_XXE.pdf
http://www.insinuator.net/2013/01/rails-yaml/
Edit:
As a clarification, I'm not implying that any of the above (apart from the DoS issue) is applicable to Django. I'm just saying what can possibly happen (and often happens for PHP apps).
peterwwillis · 2013-12-30
FWIW, this kind of problem is minor in comparison to the potential exploits that have and will continue to crop up in shared computing environments.
https://www.cs.cornell.edu/courses/cs6460/2011sp/papers/cloudsec-ccs09…
https://www.informationweek.com/security/risk-management/new-virtualiz…
http://www.insinuator.net/2013/05/analysis-of-hypervisor-breakouts/
http://slashdot.org/story/12/03/02/0059202/linode-exploit-caused-theft…
http://thoughtsoncloud.com/index.php/2013/07/how-your-data-leaks-from-…
I was trying to find any cases of a public cloud provider's customer data being leaked or easily visible on the internal customer network, but didn't come up with anything. Somebody's got to do a study on the major cloud providers and see if the good old methods to subvert network routes still works, or if you can easily mitm vm neighbors. (My guess is you can...)