Re: CVE request: rufus

["Stefan Kanthak" <stefan.kanthak () nexgo de>]

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