diff options
| -rw-r--r-- | blog/openssl-alarm-fatigue.markdown | 184 | ||||
| -rw-r--r-- | css/shim.css | 1 | ||||
| -rw-r--r-- | data/toots/9defd9a305c7c428596d01770b631bfbf82d96dd06948e996bd6e42f2de8d7d7.json | 45 |
3 files changed, 230 insertions, 0 deletions
diff --git a/blog/openssl-alarm-fatigue.markdown b/blog/openssl-alarm-fatigue.markdown new file mode 100644 index 0000000..28df84b --- /dev/null +++ b/blog/openssl-alarm-fatigue.markdown @@ -0,0 +1,184 @@ +--- +title: "OpenSSL gave everyone alarm fatigue" +date: 2022-11-01 +tags: + - openssl + - rant + - security +--- + +<xeblog-hero ai="Waifu Diffusion v1.3 (float16)" file="angy-foxgirl-disapproves" prompt="1girl, kimono, animal crossing, klaxon, loud noises, overwhelming, red sky, clouds, storms, long hair, purple hair, yellow eyes, fox ears, thick outlines, ink outlines, black outlines"></xeblog-hero> + +So, the OpenSSL security issue embargo ended today and the patches dropped. +Based on the contents of the security issue, the difficulty of exploiting it in +practice, and the fact that most Linux distributions take basic precautions to +prevent it from being a viable attack vector: this issue doesn't affect nearly +any users of OpenSSL in the real world. + +For more details on CVE-2022-3786 and CVE-2022-3602, see the OpenSSL team's post +titled [CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer +Overflows](https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/). + +<xeblog-conv name="Mara" mood="hacker">tl;dr the vulnerability is a combination +of two forces of complexity converging in a way that nobody expected: +[X.509](https://en.wikipedia.org/wiki/X.509) formats for digital certificates +and [Punycode](https://en.wikipedia.org/wiki/Punycode), an encoding standard for +putting characters that are unrepresentable in DNS into DNS (such as `我很伤心.example` +being encoded into `xn--hpq721bdf90g.example`). This works in email +addresses too. The issue was that if you gave a malformed email address in a TLS +certificate, then that could percolate up into remote code execution through a +buffer overflow on some platforms. Thankfully, that definition of "some +platforms" does not include Ubuntu on amd64 CPUs.</xeblog-conv> + +The main reason why this isn't a big deal for most people is the fact that most +modern compilers enable [stack overflow +protection](https://security.stackexchange.com/questions/158609/how-is-the-stack-protection-enforced-in-a-binary/158616#158616), +which will stop this buffer overflow from causing arbitrary code to be executed. +In practice, the stack protector will realize that something is wrong and make +the program explode. This reduces the attack from an arbitrary code execution +attack to a simple denial of service attack, which is a lot more boring in +practice. + +For more details on this, see [this +writeup](https://github.com/colmmacc/CVE-2022-3602) that explains how this +attack works, how you can replicate it at home with a vulnerable version of +OpenSSL, and ultimately why it's not a practical problem. If any organization +wanted to use this, it would almost certainly result in the certificate being +noticed on certificate transparency logs and then potentially the entire +certificate authority's ability to issue certificates would be brought into +question. This would likely end up with the certificate authority not being +allowed to issue certificates until the situations that allowed that authority +to issue certificates were fixed and independently evaluated to be fixed. + +I guess it is most viable in environments with custom TLS root certificates, but +those are rare enough in practice to not really make this a useful attack +mechanism. There's much lower-hanging fruit in the equation. Maybe people really +do distrust certificate authorities that much, though. + +<xeblog-conv name="Numa" mood="delet">Yeah, it's not like +[mTLS](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/) +exists, requires you to use custom certificate authorities and _absolutely_ +would be a great way to use this vuln to get up to no good. We don't have +anything like that at all.</xeblog-conv> + +<xeblog-conv name="Mara" mood="hmm">Oh, that could be _very bad_. Oh god that +could be so bad.</xeblog-conv> + +I feel somewhat compelled to apologize for how I've been treating the OpenSSL +issue on my blog. I took the OpenSSL team at their word, and I feel that I have +done the right thing, even if it turned out to be a giant nothingburger in +practice. If my coverage of the issues harmed you or made you worry beyond +normal, I'm sorry. I was going off of the information I was given and I had +heard from several sources I trust that it was something to really care about. I +will use this experience to help shape how I report on these things in the +future. + +<xeblog-conv name="Cadey" mood="angy">This is _technically_ meeting the +definition of "CRITICAL" in [the OpenSSL +definitions](https://www.openssl.org/policies/general/security-policy.html#critical). +This _can_ lead to arbitrary attacker-controlled code execution in theory, but +in practice it won't for the majority of users.</xeblog-conv> + +## Why I'm frustrated + +There are two big things that frustrate me about this pair of vulnerabilities. + +The first is that apparently the OpenSSL team _does not know what compiler flags +are used to compile OpenSSL on popular targets_. Like, I get it, at some level +this makes sense. OpenSSL is used in a billionty different environments and all +of them are unique snowflakes. + +However, at some level this feels a bit inexcusable. Ubuntu and CentOS are some +of the biggest users of OpenSSL. People that work for Canonical and Red Hat are +contributors to OpenSSL. I feel that they should have _some_ sense of what the +most common environments do. Sure they are not going to be able to stop some +embedded device in Palau from ACE-ing a pointer from an email address in a +certificate, but I'd certainly hope that Ubuntu and CentOS are the targets that +they _really_ care about and validate against. + +The second thing that bothers me is that it seems that it was downgraded from a +"CRITICAL" bug to a +["HIGH"](https://www.openssl.org/policies/general/security-policy.html#high) bug +earlier on today, November 1st, 2022. To give the OpenSSL team the *widest +possible* benefit of the doubt, this is somewhat reasonable. As they continued +to poke at things and research how vulnerable people were, they realized that +their initial assessment of the issue was wrong. This means that people that +were saying it was very bad were accurately reporting on what they understood at +the time. At some level this is how the process of science works: you have a +hypothesis, you test it, you report the results. It is just frustrating that it +took so long to downgrade it. I was prepared for a critical vulnerability and +I'm sure other people were too. + +I'm worried that this is going to be seen as a reason to not take "CRITICAL" +disclosures seriously at first glance like we _should_. A "CRITICAL" bug +**MUST** be treated as if it was critically bad. From a community health +perspective, people have been told that something really bad is about to come +out for _a week_ and then had the rug pulled out from under them and now it's +"nah we were wrong you're probably fine". + +Again, this happens, and it's perfectly rational for them to change their minds. +I just worry that this level of alarm fatigue has just trained people to not +take things seriously because this time it wasn't so bad. + +<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Turns out the OpenSSL advisory was more disruptive than the vulnerability.</p>— dkp (@tweetdkp) <a href="https://twitter.com/tweetdkp/status/1587537224618369032?ref_src=twsrc%5Etfw">November 1, 2022</a></blockquote> + +NixOS has stack protection enabled, so it was never vulnerable to this issue in +the first place. My [article](https://xeiaso.net/blog/nixos-nginx-openssl-1.x) +telling people to recompile nginx with OpenSSL 1.x wasn't needed. However, it +was a cool way to show off `overrides` in nixpkgs, so I'm going to consider that +a win regardless. + +## Hot Take Zone™️ + +Maybe we need to stop writing new security-critical code in C. Here is the +_entire contents_ of one of the patches that fixed +[CVE-2011-3602](https://github.com/openssl/openssl/commit/fe3b639dc19b325846f4f6801f2f4604f56e3de3): + +```diff +--- a/crypto/punycode.c ++++ b/crypto/punycode.c +@@ -181,7 +181,7 @@ int ossl_punycode_decode(const char *pEncoded, const size_t enc_len, + n = n + i / (written_out + 1); + i %= (written_out + 1); + +- if (written_out > max_out) ++ if (written_out >= max_out) + return 0; + + memmove(pDecoded + i + 1, pDecoded + i, +``` + +For those of you that don't know C that well, here's my attempt to explain +what's going on. This is in a function that decodes +[punycode](https://en.wikipedia.org/wiki/Punycode) text into its corresponding +Unicode text. One of the things it does is copy data from the input buffer, +decode it, and then put the results in an output buffer. This if statement is +here to prevent the buffer from running over and into whatever comes next. If +that "whatever comes next" is in the stack, then the value can potentially +overflow and then that value becomes the return address for when that function +is called. + +The root cause of this is an off-by-one out-of-bounds write to the output +buffer. This is made possible because C does not have ways for you to statically +prove that you cannot overwrite buffers like this such that the compiler will +refuse to compile the code. + +Maybe as an industry we need to start taking formal verification, memory safety, +and related things a bit more seriously. Maybe adding Rust to the Linux kernel +is a good thing. [Rust was also recently added to the Windows +kernel](https://twitter.com/dwizzzleMSFT/status/1578532292662005760) without +anyone really noticing its presence. + +<xeblog-conv name="Cadey" mood="coffee">Or at least we can work towards +lessening our dependencies on C for security-critical infrastructure like TLS +session management with things like +[rustls](https://docs.rs/rustls/latest/rustls/) or using Go's +[crypto/tls](https://pkg.go.dev/crypto/tls).</xeblog-conv> + +<xeblog-conv name="Numa" mood="delet">But if we write things in Rust then it +won't work on my Alpha VAX cluster full of OpenVMS machines that runs the logic +for a secure cluster of Gopher servers!</xeblog-conv> + +<xeblog-sticker name="Cadey" mood="coffee"></xeblog-sticker> + +<xeblog-toot url="https://pony.social/@cadey/109270702249158842"></xeblog-toot> diff --git a/css/shim.css b/css/shim.css index 15f88af..589dd59 100644 --- a/css/shim.css +++ b/css/shim.css @@ -31,6 +31,7 @@ img { .conversation-smol { min-width: 6rem; max-width: 6rem; + padding: 0.5rem; } .conversation-chat { diff --git a/data/toots/9defd9a305c7c428596d01770b631bfbf82d96dd06948e996bd6e42f2de8d7d7.json b/data/toots/9defd9a305c7c428596d01770b631bfbf82d96dd06948e996bd6e42f2de8d7d7.json new file mode 100644 index 0000000..24b9117 --- /dev/null +++ b/data/toots/9defd9a305c7c428596d01770b631bfbf82d96dd06948e996bd6e42f2de8d7d7.json @@ -0,0 +1,45 @@ +{ + "id": "https://pony.social/users/cadey/statuses/109270702249158842", + "type": "Note", + "inReplyTo": null, + "published": "2022-11-01T21:36:36Z", + "url": "https://pony.social/@cadey/109270702249158842", + "attributedTo": "https://pony.social/users/cadey", + "to": [ + "https://www.w3.org/ns/activitystreams#Public" + ], + "cc": [ + "https://pony.social/users/cadey/followers" + ], + "sensitive": false, + "atomUri": "https://pony.social/users/cadey/statuses/109270702249158842", + "inReplyToAtomUri": null, + "conversation": "tag:pony.social,2022-11-01:objectId=5786977:objectType=Conversation", + "summary": null, + "content": "", + "contentMap": { + "en": "" + }, + "attachment": [ + { + "type": "Document", + "mediaType": "image/png", + "url": "https://cdn.pony.social/file/tscs37-pony-social/media_attachments/files/109/270/700/767/816/207/original/c1ff4360610ded0c.png", + "name": "", + "blurhash": "UDPQT,bw~qoJ?aMwRQWCxatRofj?9GtRoyae", + "width": 480, + "height": 480 + } + ], + "tag": [], + "replies": { + "id": "https://pony.social/users/cadey/statuses/109270702249158842/replies", + "type": "Collection", + "first": { + "type": "CollectionPage", + "next": "https://pony.social/users/cadey/statuses/109270702249158842/replies?only_other_accounts=true&page=true", + "partOf": "https://pony.social/users/cadey/statuses/109270702249158842/replies", + "items": [] + } + } +}
\ No newline at end of file |