Akeo Consulting Information for VU#403768

Akeo Consulting Rufus fails to update itself securely

Status

Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

You do realize that the executable is digitally signed, in which case the matter in which it was download does not matter, do you?

I would encourage you to further your knowledge of security practices, because, just because something says "secure" in its name, it doesn't mean that it is actually secure (the transmission of data is "secured", but if the source download is compromised, which is something that's fairly easy to achieve if you physically threaten the person administering the server, downloading through SSL won't bring you any "security"), or just because something does not say "secure", it doesn't mean that it is insecure if it is digitally signed. Likewise, people tend to believe that self signed certificates are more insecure that the ones issued by Certification Authority, but there are occasions where they are actually safer. I've been dealing with PKI matters for more than 15 years, and written quite a few applications that revolve around it, so I hope that, rather than jumping to the conclusion that experienced developers don't know what they are doing, you will actually take the approach that, maybe, they have greater knowledge than you do about security matters, and, because of it, they can make educated decisions about discarding security practices that are entirely redundant and aren't bringing anything to the equation. You may also want to read the second part of what I wrote here when I was recently questioned about the same subject.

As a matter of fact, the next version of Rufus will switch the update check (and other downloads) back to http rather than https (8b094e8), because, due to the way Rufus is designed, using http does not make our downloads any less "safe", even if the NSA or whatever 3-letter security agency has control of the connection and attempts to inject malicious content into it.

Now, provided you spend time reading and understanding the topics being discussed on our page about Security in Rufus and especially this part, I'll be happy to debunk any scenario you can propose, where you think the use of HTTP in Rufus is going to make its users less secure than if HTTPS was used.

Vendor References

https://github.com/pbatard/rufus/issues/1009#issuecomment-325415199

Addendum

There are no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.