Date: Thu, 09 Aug 2018 15:34:42 +0000 From: Stiepan <stie@....swiss> To: oss-security@...ts.openwall.com Subject: Re: Linux TCP implementation vulnerable to Denial of Service (CVE 2018-5390) Hi, Thank you for fighting censorship on what is supposed to be a list for managing security issues of open software. The issue is that it has gone so far from its original idea, with the embargoes and removal of direct CVE requests, that legal action remains the only logical one, for anyone not part of the "club". As to getting some funding to run it properly, I continue to do think it would make sense, if you can ensure independence from a specific organization or government's interest (cc-ing Google, not ITU or Protonmail, arbitrarily, says long on this very issue and the one of Linux governance overall). Best, Stiepan A. Kovac President itk AVtobvS SARL Envoyé depuis ProtonMail mobile -------- Message d'origine -------- On 9 août 2018 à 14:51, Solar Designer a écrit : > Hi, > > A co-moderator had rejected Stiepan's message since it "does not provide > any additional content to oss-security readers". I'm also unhappy about > that, as well as about the focus on legal aspects in Stiepan's postings > in here in general. However, the message raises an on-topic question > (the request for more detail) and brings up an on-topic issue (the > semi-embargo potentially causing harm). I feel strongly about us not > getting into censorship, and I feel that rejecting this message would be > it. So I went for the effort of manually restoring the already-rejected > message into the moderation queue, then approved it. > > On Thu, Aug 09, 2018 at 07:12:27AM +0000, Stiepan wrote: >> Could you please provide some more details on the issue? > > I agree that more detail must have been posted in here, especially given > that such detail was on linux-distros. > > The issue is now also public via CERT: > > https://www.kb.cert.org/vuls/id/962459 > > which links to: > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=1a4f14bab1868b443f0dd3c55b689a478f82e72e > > which includes the following detail: > > --- > Juha-Matti Tilli reported that malicious peers could inject tiny > packets in out_of_order_queue, forcing very expensive calls > to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for > every incoming packet. > > With tcp_rmem default of 6MB, the ooo queue could > contain ~7000 nodes. > > This patch series makes sure we cut cpu cycles enough to > render the attack not critical. > > We might in the future go further, like disconnecting > or black-holing proven malicious flows. > --- > > The CERT Vulnerability Note also talks about a related issue in FreeBSD. > > Partial timeline for this issue as I became aware of it is as follows: > > 2018/07/23 - the commit referenced above > 2018/07/23 - notification from CERT to some distros > 2018/07/23 - grsecurity tweet linking to the commit > 2018/07/27 - posting to linux-distros > 2018/08/06 - CERT Vulnerability Note published > 2018/08/08 - posting to oss-security > > Of course, I am unhappy about this semi-embargo, and even more unhappy > about the semi-violation of linux-distros list policy on only having > non-public issues in there. However, with CERT involved and with > related issues affecting more than just Linux, there was little I could > do, short of playing full BOFH and breaking the semi-embargo for > everyone. While I think that would have been for the general public's > benefit overall, I didn't feel about it strongly enough to actually do > it this time. I apologize for letting this happen. (At the same time, > I did force another semi-public issue to oss-security right away since > that one didn't involve coordination with so many parties.) > > It appears that everyone involved, including the CERT people, Matthew, > and others commenting on the linux-distros thread, were unhappy about > the publication delay. No one I saw said that they wanted the delay. > Yet somehow CERT didn't pull the trigger sooner. I guess two weeks > feels very soon for CERT as it is, even if it is a very long embargo for > linux-distros. Also, I guess the discoverer/reporter of the issue had a > say on it behind the scenes, and other related issues and non-Linux were > considered in CERT's decision-making. > > I am also unhappy about the two-day delay between publication of the > CERT Vulnerability Note and the mandatory posting to oss-security (it's > mandatory since the issue was on linux-distros). I've been pinging > off-list to make this happen at all, and would have probably made the > posting myself if it didn't happen for another day. > >> About the same period, our secure e-mail provider suffered an unprecedented DDoS with some e-mail messages never reaching us. >> Since this has business impact, > > This is almost certainly unrelated. (And I dropped the CC's to > ProtonMail and ITU on this reply, not to spam them with further > discussion of the unrelated issue.) > >> we consider legal action against the opaque Linux-distros vulnerability-disclosure-among-friends-for-fun-and-profit scheme, that we exposed at the ITU earlier this year. This is digital divide in the works, with real impact for non-club-members. > > Personally, I strongly oppose legal threats (let alone action) in our > community. The way I see it, what we have is primarily a matter of > different opinions on how to handle security issues best, and most > people are genuinely acting the way they think works best for everyone > affected. With many parties involved in coordinating a disclosure, it > usually becomes difficult. There isn't necessarily a right or wrong > here. But whoever brings legal action is definitely wrong. > > Ironically, Stiepan had also suggested (here on oss-security a while > ago) that we apply for funding for running the (linux-)distros list (and > I explained in a reply why we shouldn't). > > Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.