Date: Thu, 31 May 2018 20:04:52 +0200 From: "Stefan Kanthak" <stefan.kanthak@...go.de> To: "Pete Batard" <pete@...o.ie> Cc: <oss-security@...ts.openwall.com> Subject: Re: CVE request: rufus Pete, > Hi Stefan, > > Thank you very much for your very depreciative and less than informative > report. As always, your poor reading skills perfectly match your poor programming skills. READ THE SUBJECT! Hint: it reads "CVE request". > Since a vulnerability report works a lot better with an actual > exploitation scenario conducted with the actual application, that we can > look into, we will be waiting on that from you. "We" wait until the requested CVEs are assigned for both well-known vulnerabilities. > Also, FYI, we did apply mitigation for #1 (DLL sideloading attacks) very > shortly after the time it became publicized: > https://github.com/pbatard/rufus/commit/8473e9ef561295fd10dd9526010c1fd1cb1e6701 OUCH! Or shall I write: BWAHAHAHA!? DLL spoofing was VERY well known long before 2016, and it is neither restricted to the CWD nor to runtime linking: a) in 1996, the NSA-sponsored report "An intro to... Windows NT security" (its copy <http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm> is unfortunately gone) was published; b) in 2000, Georgi Guninski published <http://www.guninski.com/officedll.html> b) in 2006, the paper "DLL Spoofing in Windows" <https://www.it.uu.se/edu/course/homepage/sakdat/ht05/assignments/pm/programme/DLL_Spoofing_in_Windows.pdf> was published; c) in 2008, Microsoft's David LeBlanc wrote <https://blogs.msdn.microsoft.com/david_leblanc/2008/02/20/dll-preloading-attacks/>, while CERT's Will Dormann wrote <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html> d) in 2010 and 2012, Acros Security published <http://www.binaryplanting.com/> plus <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> e) since then, Microsoft published <https://technet.microsoft.com/en-us/library/2269637.aspx>, <https://msdn.microsoft.com/en-us/library/ff919712.aspx>, <https://msdn.microsoft.com/en-us/library/ms682586.aspx> and <http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx> I recommend to do YOUR homework first, BEFORE you dare to publish software riddled with well-known and well-documented vulnerabilities, which allows escalation of privilege. It's YOUR duty to protect YOUR users. As a starting point, read and try to understand <https://skanthak.homepage.t-online.de/sentinel.html> and <https://skanthak.homepage.t-online.de/!execute.html> When done, continue with <https://skanthak.homepage.t-online.de/verifier.html> and <https://skanthak.homepage.t-online.de/minesweeper.html> Until then, to protect your users, remove Rufus from the net! > And of course, with proper non disparaging involvement of security > researchers, who subscribe to the established responsible disclosure > policy of their profession, we are always eager to improve on our > mitigation fixes, if it turns out they aren't adequate. > > However, we would appreciate if you refrained from jumping to erroneous > conclusion about Rufus development being conducted by "bloody > beginners", when it is clear that some of the "beginner's" > vulnerabilities you list have long had some mitigation factors applied. I recommend to read the advice other people gave you on <https://github.com/pbatard/rufus/issues/1009>: SOME mitigations are clearly NOT sufficient, especially if you choose to apply the WRONG and IMPROPER mitigations. Stefan Kanthak PS: I might even show you that pasting the string "rufus.com" to the window which has the focus yields interesting effects. > All the best, > > /Pete > > > On 2018.05.31 17:05, Stefan Kanthak wrote: >> Hi @ll, >> >> like its predecessors, the recently (2018-05-29) published version >> 3.0 of "Rufus" (<https://rufus.akeo.ie/downloads/rufus-3.0.exe> and >> <https://rufus.akeo.ie/downloads/rufus-3.0p.exe>) is riddled with >> bloody beginners errors, which allow arbitrary code execution WITH >> escalation of privilege. >> >> Vulnerability #1 >> ~~~~~~~~~~~~~~~~ >> >> See <https://cwe.mitre.org/data/definitions/426.html> >> and <https://cwe.mitre.org/data/definitions/427.html> >> plus <https://capec.mitre.org/data/definitions/471.html>. >> >> Additionally see Microsoft's developer guidance >> <https://technet.microsoft.com/en-us/library/2269637.aspx>, >> <https://msdn.microsoft.com/en-us/library/ff919712.aspx>, >> <https://msdn.microsoft.com/en-us/library/ms682586.aspx> und >> <http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx> >> for avoiding this bloody beginner's error. >> >> Also see >> <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html> >> and >> <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> >> plus >> <https://insights.sei.cmu.edu/cert/2016/06/bypassing-application-whitelisting.html> >> for "prior art". >> >> >> Vulnerability #2 >> ~~~~~~~~~~~~~~~~ >> >> See <https://cwe.mitre.org/data/definitions/377.html> >> and <https://cwe.mitre.org/data/definitions/379.html> >> plus <https://capec.mitre.org/data/definitions/29.html> >> >> stay tuned >> Stefan Kanthak >>
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ