1. 2

      Heh. Maybe there will be better discussion of it here as that was mostly off-topic. I’m not sure I’ve got anything useful to add other than what’s in the article or the paper. I’m not surprised by any of this but it is incredibly annoying and I’m sure it doesn’t end here. We’re going to need new and better mitigations because these things won’t be “fixed”. I can’t stand spender (grsec guy) but he’s definitely been right about KASLR at least as it applies to the linux kernel.

    1. 1

      Might be easier to link to the abstract: https://arxiv.org/abs/2008.02307

      1. 2

        easier for what exactly? The abstract is part of the paper in the link.

        I linked to what I intended to link to and emphasized what I intended to in my comment.

        1. 0

          Because that way you don’t need to paste a summary of the abstract into a comment, it’s available immediately after clicking.

          1. 1

            It’s available in the original link and the comment was meant to emphasize a specific sentence.

      1. 4

        from the abstract:

        We demonstrate that these dereferencing effects exist even on the most recent Intel CPUs with the latest hardware mitigations, and on CPUs previously believed to be unaffected, i.e., ARM, IBM, and AMD CPUs.

          1. 2

            I have merged stories mnpjst and bqw8wv in to story jb8fpk. Thank you for keeping track of them.

            1. 3

              I find this a strong article that is relevant to us techies, but I know that this is on the verge of being off-topic and I know that I am biased (Mozilla employee).

              Looking forward to seeing whether this gets a discussion or a downvote :-)

              Happy Friday!

              1. 3

                Stories can’t be downvoted here.

                1. 1

                  Yeah, I meant flagged as off topic. I got what I asked for :-))

                2. 2

                  I marked this as spam because it looks like spam to me. I suppose there could be debate about whether this is spam or just off-topic?

                1. 1

                  Dropping a dissertation on us with no tl;dr comment? Lol at least it’s a short one at 96 pages.

                  Here’s my shot at a tl;dr:

                  Data oriented attacks can corrupt program execution, without triggering protection mechanisms such as DEP, ASLR, and CFI. This research systematizes the topic area (see also their 2019 Oakland SoK), then discusses advancements to an existing approach (data space randomization, to prevent targeted corruptions, Asia CCS ‘20) and a new approach (type-checking variadic function arguments, Usenix Security ‘17).

                  1. 1

                    The abstract of the paper is the TL;DR.

                  1. 1

                    This was already posted. Also should have (2015) in the title.

                    From 2 years ago: https://lobste.rs/s/z736eo/ideology_talk_by_gary_bernhardt_from

                    @alynpost Is this something that should be merged or is that not a thing for such an old post?

                    1. 2

                      I agree on the (2015) in the title, unfortunately I can’t make any changes to it now, so maybe a moderator could do that?

                      This was submitted before, 2 years ago and had no discussion (there’s a link at the bottom). I resubmitted it because its contents is still relevant and I’m happy to see it brought up a bit of a discussion and potentially reached a new audience.

                    1. -3

                      This seems like self-congratulatory nonsense to me. Marked as spam.

                        1. 6

                          I upvoted because it expresses a pattern of behaviour that I’ve noticed in djb for well over 20 years now, and have come across myself. Many years ago I noticed a bug in qmail-imapd where it wasn’t implementing a part of the RFC at all, and it was breaking some IMAP clients. djb said that that part of the RFC wasn’t important and refused to implement it, forcing many of our end users to switch their email clients and causing a lot of head-aches. because of that, and a few other interactions, I have never used another piece of software by djb, even though it might be in many ways technically better. It’s just not worth the headaches of having to deal with him

                          1. 5

                            djb is genius-level smart, and find many of his programs have a kind of rare brilliance to them. In an alternative universe where he’s not such a pain to deal with we’d all be running qmail instead of postfix and daemontools instead of systemd.

                            1. 1

                              Yep. It’s actually quite a shame, really.

                              1. 1

                                There’s usually saner implementations of the same idea — namely runit for daemontools. And most famously libsodium for NaCl.

                                As for mail.. qmail seems arcane and complicated. OpenSMTPd is the only mail server I’d be willing to admin :D

                                1. 1

                                  i tried setting opensmptd up with virtual users / virtual domains using sqlite and to my surprise it didn’t work anymore as the opensmptd-extras have a version mismatch in debian, so postfix it is again. maybe more of a debian problem than opensmptd.

                              2. 3

                                Many years ago I noticed a bug in qmail-imapd where it wasn’t implementing a part of the RFC at all, and it was breaking some IMAP clients

                                There is no qmail-imapd.

                                djb said that that part of the RFC wasn’t important and refused to implement it

                                No he didn’t, because there is no qmail-imapd.

                                1. 1

                                  Huh, you’re absolutely right about there not being an imap server associated with qmail. I wonder what program the bug was associated with. It was nearly 20 years ago, so aspects of it may be entirely wrong.

                                2. 2

                                  Wait, there is a qmail-imapd ? I would be happy to know where you found it, as I fail to see it in the qmail source, and all I find for “qmail-imapd” is tcp rules for courrier-imap as part of some qmail metapackage : https://www.opennet.ru/base/patch/qmail_ldap.txt.html

                                  1. 1

                                    I think djb is a jackass but I flagged this as off-topic for basically the same reason as @gerikson

                                  1. 1

                                    really with this?

                                    @alynpost can we merge this with https://lobste.rs/s/ti21d7/opensmtpd_6_6_4p1_released_addressing ?

                                    You can correct me if this shouldn’t be merged but I don’t see the point in a new post for this.

                                    1. 2

                                      Thank you @fro. I have merged story nxn7jz in to story ti21d7.

                                      Your request to merge is correct. The article, despite being the same CVE, is a substantive update, adding three sections that can now be published. It’s appropriate that story nxn7jz was submitted [for merge]–it’s routine for credit, acknowledgments, exploits, or more detailed data to be published in this fashion as part of the responsible disclosure process.

                                    1. 9

                                      Securing MTA must be a cursed job.

                                      Back in the old days we had near weekly RCEs in sendmail and exim and these days it’s OpenSMTPD with strong ties to the f’ing OpenBSD project. That’s the one project I expect an RCE the least from; much less two in as many months.

                                      Email is hard.

                                      1. 5

                                        It’s actually 3 — this one has two separate CVE’s in a single release, including a full local escalation to root on Fedora due to Fedora-specific bugs adding an extra twist (CVE-2020-8793).

                                        The other bug here (CVE-2020-8794) is a remote one in the default install; although the local user still has to initiate an action to trigger an outgoing connection to an external mail server of the attacker, so, I guess OpenBSD might not count it towards the remote-default count of just two bugs since years ago.

                                        1. 2

                                          I guess OpenBSD might not count it towards the remote-default count of just two bugs since years ago.

                                          I feel like that would be disingenuous. I realize it’s not enabled by default in a way that’s exploitable but in the default install there’s literally nothing running that’s even listening really (you can enable OpenSSH in a default install, I suppose); this is of course the correct way to configure things by default. However, the statement degenerates to “no remotely exploitable bugs in our TCP/IP stack and OpenSSH”…which is awesome, but…

                                          (Also, it’s easy to criticize: I’ve never written enterprise grade software used by millions.)

                                          1. 1

                                            Can you explain more about why you think that’s disingenuous? OpenBSD making this claim doesn’t seem different to me than folks saying that this new bug is remotely exploitable. It’s very specific and if something doesn’t meet the specific criteria then it doesn’t apply. Does that make sense?

                                            It is my opinion that the statement should be removed – not because it’s not accurate but because I just think it’s tacky.

                                            1. 4

                                              IMHO it’s disingenuous because it implies that there are only two remote holes in a heck of a long time on a working server. It’s like saying “this car has a 100% safety record in its default state,” that is, turned off.

                                              (I’m reminded of Microsoft bragging about Windows NT’s C2 security rating, while neglecting to mention that it got that rating only on a system that didn’t have a network card installed and its floppy drive glued shut.)

                                              I’m not sure if they include OpenSSH in their “default state” (I think it is enabled by default), but other than OpenSSH there’s nothing else running that’s remotely reachable. Most people want to use OpenBSD for things other than just an OpenSSH server (databases, mail servers, web servers, etc), and they might get an inflated sense of security from statements like that

                                              (Note that OpenBSD is remarkably secure and their httpd and other projects are excellent and more secure than most alternatives, but that’s not quite the point. Again, it’s easy for me to criticize, sitting here having not written software that has been used by millions.)

                                              1. 2

                                                I appreciate you taking the time to elaborate. I think the claim is tacky as it seems to be more provocative than anything else – whether true or not. I don’t think it’s needed because I think what OpenBSD stands for speaks for itself. I think I understand why the claim was used in the past but this conversation about it comes up every time there’s a bug – whether remote or not. The whole thing is played out.

                                                1. 2

                                                  AFAIK OpenSMTPD is enabled by default, but does local mail delivery only with the default config. This makes the claim about “only 2 remote holes” still stand still, though I agree with your analysis of bullshit-o-meter of this slogan. But hey, company slogans are usually even more bullshit-ridden, so I don’t care.

                                            2. 1

                                              You’re saying a local user has to do something to make it remote? Can you explain how that makes it remote?

                                              1. 2

                                                One of the exploitation paths is parsing responses from remote SMTP servers, so you need to request that OpenSMTP connect out to an attacker-controlled server (e.g. by sending email).

                                                It looks like on some older versions there’s a remote root without local user action needed…

                                                1. 1

                                                  I reckon I’ll go back and read the details again. However, if something requires that a local user do a very specific thing under very specific circumstances (attacker controlled server, etc.) in order to exploit – that does not jive with my definition of remote.

                                                  1. 3

                                                    Apparently you can remotely exploit the server by triggering a bounce message.

                                            3. 2

                                              Step zero is don’t run as root and don’t have world writable directories.

                                              .

                                              .

                                              .

                                              Sorry, was I yelling?

                                              1. 4

                                                Mail is hard that way in that the daemon needs to listen to privileged ports and the delivery agent needs to write into directories only readable and writable by a specific user.

                                                Both of these parts require root rights.

                                                So your step zero is impossible to accomplish for an MTA. You can use multiple different processes and only run some privileged, but you cannot get away with running none of them as root if you want to work within the framework of traditional Unix mail.

                                                Using port redirection and virtual users exposing just IMAP you can work around those issues, but them you’re leaving the traditional Unix setup and you’re adding more moving parts to the mix (like a separate imap daemon) which might or might not bring additional security concerns

                                                1. 2

                                                  At least on Linux there’s a capability for binding into privileged ports that is (the cap) not equivalent to root.

                                                  1. 3

                                                    yes. or you redirect the port. but that still leaves mail delivery.

                                                    As I said in my original comment: email is hard and that’s ok. I take issue with people reducing these vulnerabilities (or any issue they don’t fully understand) to “just do X - it’s so easy” (which is a strong pointer they don’t understand the issue)

                                                    Which is why I sit in my rant about still using C for (relatively) new projects when safer languages exist, though - oh boy is it tempting to be dropping a quick “buffer overflows are entirely preventable in as-performant but more modern languages like rust. why did you have to write OpenSMPTD in C”, but I’m sure there were good reasons - especially for people as experienced and security focused as the OpenBSD folks.

                                                    1. 3

                                                      It’s hard if you impose the constraint that you need to support the classical UNIX model of email that was prevalent from the late 70s to the mid 90s. I was once very attached to this model but it’s based on UNIX file-system permissions that are hard to reason about and implement safely and successfully. The OpenSMTPD developers didn’t make these mistakes because they’re stupid, it’s really really hard. But it’s an unfortunate choice for a security focused system to chose to implement a hard model for email rather than making POP/IMAP work well, or some other approach to getting email under the control of a the recipient without requiring priviledges.

                                                  2. 1

                                                    Not sure any of these are true, but more of a self-imposed traditional limitation.

                                                    Lower ports being bindable by root only could easily be removed; given linux has better security mechanisms to restrict lower port binding, like selinux, I’m not even sure why the kernel still imposes this moronic concept on people. Mail delivery (maildir, mbox, whatever zany construct) can also be done giving limited rw access to the specific user and the MDA. hell, MAIL on my system just points to /var/spool/mail which is owned by root anyhow.

                                                    1. 1

                                                      selinux isn’t everywhere.

                                                1. 2

                                                  Thank you @fro. When I first saw your request (prior to your adding a link to the story to merge in to) I thought the story you were asking to merge referred to CVE-2020-7247 / OpenSMTPD 6.6.2p1, which has fallen outside the merge window. I quickly realized you meant story ti21d7 / OpenSMTPD 6.6.4p1, and they are now merged.

                                                  1. 2

                                                    Yeah I was a bit late on the link. Thanks!

                                                1. 3

                                                  CPU manufacturers have been ignoring security for a long time, relying on obscurity. My pessimistic observation is this:

                                                  1. Some researchers look under a rock (i.e CPU), find bad security.
                                                  2. It becomes trendy to look under these rocks, other researchers join the fun.
                                                  3. Repeat

                                                  This may be a bit tautological, but if you want to find new vulnerabilities as a security researcher, it seems as simple as to look where others haven’t and aren’t, for whatever reason. And I think the nature of academia discourages this, so it’s not tough to think of.

                                                  This comment may be a bit of an oversimplification. I know some things about security, but I’m by no means an expert. Am I wrong here?

                                                  1. 2

                                                    I’m no expert but I agree with the sentiment and think there is definitely truth in what you’re saying here.

                                                    1. 2

                                                      Thank you @gerikson, I have merged the stories regarding CVE-2020-7247.

                                                      1. 1

                                                        I don’t think the post-mortem should be merged into this.

                                                        1. 2

                                                          Will you explain why?

                                                          1. 2

                                                            It is now buried here with older posts. It also contains more information on how it happened, why it happened, what was done to fix it, and future plans. It’s more recent than the others and potential discussions from a detailed post-mortem seem worthwhile to me and they’re less likely to happen here now.

                                                            1. 4

                                                              The reason I merged story 4gd1oz (“OpenSMTPD advisory dissected”) in to story wcgwqk (“LPE and RCE in OpenSMTPD (CVE-2020-7247)”) was that both stories covered the same topic, and were submitted within two weeks of each other. This has been how story merging has been used since it was implemented in August 2014:

                                                              Similar stories such as multiple sites reporting about the same news topic, or duplicates not found by the duplicate detection code should be able to be merged into one story.

                                                              To determine whether a two stories cover the same topic, I use the following tests:

                                                              A) Is the article for the newly submitted story a near-duplicate of the article for the previously submitted story? i.e., was the material republished or rebroadcast?

                                                              B) Does the article for the newly submitted story reference or link to the article for the previously submitted story? i.e., is it a response or follow-up? (Occasionally described as a hot take.)

                                                              C) Does the article for the newly submitted story discuss the same situation or event as the article for the previously submitted story link? i.e., are there multiple sources?

                                                              D) Does the article for the newly submitted story cover the same subject matter as the article for the previously submitted story link? e.g., is it a source code repository for a project that was the subject of a blog post?

                                                              E) In all cases, is the newly submitted story submitted no later than two weeks after the previously submitted story?

                                                              Any one of tests A-D are sufficient to merge, so long as test E holds.

                                                              Here, I merged story 4gd1oz because it passed test C: the topic (in this case the situation under discussion) for both articles being the “Qualys Security Advisory for OpenSMTPD (CVE-2020-7247)”, and test E: story wcgwqk was submitted on or about Wed, 29 Jan 2020 and story 4gd1oz was submitted on or about Fri, 31 Jan 2020. Approximately two days apart.

                                                              It is a near-certainty that later published stories will contain more information (“It also contains more information on how it happened, why it happened, what was done to fix it, and future plans”) due to the straightforward fact that more time was available to communicate with others. Variation in information content of an article doesn’t pertain to topicality, however. Stories are merged when they cover the same topic.

                                                              There has been at least one experiment to address your first reason (“It is now buried here with older posts”) due to similar report in issue 300. It was eventually reverted in commit c602b01 having been deployed less than a month.

                                                              If you’re able to describe an improvement to the hotness calculation for merged stories that you think would substantively address your last reason (“potential discussions from a detailed post-mortem seem worthwhile to me and they’re less likely to happen here now”) I’d encourage you or anyone reading to submit a PR for review. An advantage of the current hotness behavior is that a story cannot be kept alive via “trickle” of newly submitted, merged stories–a story submission behavior we do see with multiple part blog posts. Changes to how hotness is calculated on merged stories need to account for all reasons a story is merged (i.e., the merge tests articulated here). A significant majority of story merges are unremarkable and a PR should aim to incrementally make more of them so.

                                                              If you or anyone reading is able to improve the series of tests I use to decide whether a story should be merged, please voice it. Note however that where possible, I have removed discretion from the decision to merge a story via use of these tests. I’m not interested in adding discretion back in to the process. Doing so would not be an improvement. More decidability, not less.

                                                              I hope this explanation adequately describes the trade-offs involved in merging stories, why story 4gd1oz was merged, and can serve as a guide to understanding how this feature as currently implemented is and will be used.

                                                              1. 1

                                                                Stories are merged when they cover the same topic.

                                                                Does that only happen by request? I see other stories about the same topic that are not merged.

                                                                1. 1

                                                                  I merge those stories I notice that other folks haven’t already suggested. If you see one you’re welcome to suggest it get merged–gerikson highlighted me for story n9ttxa here.

                                                                  1. 1

                                                                    I just wanted to make sure I was understanding this all correctly. Thanks for the very detailed explanation of everything.

                                                              2. 2

                                                                I fully agree with @fro here.

                                                                The CVE was “am I affected? no? ignore. yes? patch.”

                                                                This is potentially interesting for anyone who writes software :)

                                                      1. 2

                                                        Interesting work! Suggested appending “(2001)” to the title, since that’s when the usenix paper was published. The link on the slides is no longer served.

                                                        1. 1

                                                          good lookin out!