ER: Avoid prompts that users may not properly intepret on update signature validation

[wdormann]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
• I clicked the Log button in Rufus and copy/pasted the log into the line that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Issue description

Rufus checks for updates over HTTPS, however the update itself is downloaded over HTTP, which is insecure. See also:
https://insights.sei.cmu.edu/cert/2017/06/the-consequences-of-insecure-software-updates.html

Log

Rufus version: 2.15.1117
Windows version: Windows 7 SP1 32 bit
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02
System locale ID: 0x0409
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
0 devices found
Checking for Rufus updates...
Checking release channel...
New release version found!
Downloading 'rufus-2.16.exe' from http://rufus.akeo.ie/downloads/rufus-2.16.exe
File length: 961144 bytes
Successfully downloaded 'rufus-2.16.exe'

[pbatard]

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.

[wdormann]

Thanks for the lesson, and sorry to have wasted your time.
I've written up further details here: https://www.kb.cert.org/vuls/id/403768

[pbatard]

Thanks for the lesson

Apparently not.

I've written up further details here: https://www.kb.cert.org/vuls/id/403768

And below is the e-mail I just sent to cert.org to let them know that the vulnerability you choose to report can easily be debunked (once again, if you believe that you have uncovered a vulnerability in Rufus, I'll be more than happy to discuss it with you to confirm its validity.)

Hi,

We are the authors of the software described in this CVE, and we have valid reasons to believe that this report is erroneous because the reporter failed to look at the Rufus code (which is Open Source) carefully.

As per the report:

it does not ensure that the update was signed by a trusted certificate authority (CA). This lack of CA checking allows the use of a self-signed certificate.

This is incorrect.

1. After retrieving the update binary from the download server, Rufus invokes the function call ValidateSignature() [1].

2. The ValidateSignature() invokes the Windows API call WinVerifyTrust() with parameter WINTRUST_ACTION_GENERIC_VERIFY_V2 [2].

3. As per Microsoft's documentation [3], WINTRUST_ACTION_GENERIC_VERIFY_V2 "verifies a file or object using the Authenticode policy provider."

Because the Authenticode policy provider is being invoked, and as opposed to what the reporter erroneously asserts, the signature validation is not expected to succeed if the binary is using a self-signed certificate, unless that certificate was previously added to the root store as trusted. But of course, this scenario would require the target machine to already have been compromised at administrative level (to insert that certificate in the Trusted root store) and therefore makes the whole vulnerability moot.

Furthermore, Rufus does add the flags WTD_REVOKE_WHOLECHAIN and WTD_REVOCATION_CHECK_CHAIN to ensure that whole certificate chain (including the root certificate) is also being validated for revocation, which should provide some indication that the whole chain is being validated.

Finally, since the author of this report decided to log this issue without engaging us about the perceived lack of CA checking, whereas we clearly indicated to them that we would be happy to discuss any scenario where they thought they had uncovered a vulnerability, we have reasons to believe that this report was logged out of disgruntlement, after we tried to explain to them that the use of SSL was not a panacea, and that there existed alternate means to ensure the integrity of the data being transmitted over "insecure" connections. This reporter certainly chose not to engage with us about the perceived lack of CA validation, and instead chose to abruptly end the conversation to create this Vulnerability Report, without bothering to consult us about its actual validity.

As per our detailed page on the security matters related to our software [4] and how we are taking action to address or mitigate risks, we therefore hope that you can agree that this Vulnerability Note needs to be further reviewed, before it can be acknowledged as factual.

Of course, we remain at your disposal should you need any additional details.

Regards,

/Pete Batard
Akeo Consulting

[1] https://github.com/pbatard/rufus/blob/master/src/stdlg.c#L1674-L1679
[2] https://github.com/pbatard/rufus/blob/master/src/pki.c#L279
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa388208.aspx
[4] https://github.com/pbatard/rufus/wiki/Security

[wdormann]

Given that the update occurs over a transport layer that doesn't provide security (HTTP), all verification relies on the code signature.

First, we can try providing an unsigned calc.exe, which is downloaded successfully. We then press "Launch":

rufus/src/pki.c

Line 245 in 36cadcf

MessageBoxExU(hDlg, lmprintf(MSG_284), lmprintf(MSG_283), MB_OK | MB_ICONERROR | MB_IS_RTL, selected_langid);

OK, so it's checking if the payload is signed. Let's see the behavior of pressing "Launch" with an arbitrary self-signed calc.exe that was just downloaded:

rufus/src/pki.c

Line 256 in 36cadcf

if (i >= ARRAYSIZE(cert_name)) {

What about if we self-sign calc.exe as "Akeo Consulting" ? We click launch after this binary is downloaded:

We get a generic warning from Windows "The publisher could not be verified. Are you sure you want to run this software". This is the same text that Windows gives you when you download an unsigned binary.

We click Run, as we trust that Rufus is doing its best to protect us:

Conclusion: Rufus insufficiently protected the integrity of the update process, due to use of an insecure transport, combined with insufficient validation of signed code.

[pbatard]

Conclusion: Rufus insufficiently protected the integrity of the update process, due to use of an insecure transport, combined with insufficient validation of signed code.

I beg to differ. You get an explicit warning with a big X mark stating that the signature has failed validation and that "You should only run software from publishers you trust". How's that a security risk? How's that even a "generic warning"?

If you are security conscious, you will pay heed to this warning.
If you aren't, you're probably going to run unsigned software outside of software updates anyway.

You do realize that, to pretend there exists a vulnerability, you explicitly choose to run an executable that Windows told you you should probably not run... There's only so much hand-holding an application will do for you.

Oh, and also, this has nothing to do with HTTP. If the server gets hacked (which is a lot less of a remote possibility than injecting content in an HTTP session), someone can also place a self-signed executable and generate the same behaviour.

[wdormann]

Running Rufus when you're connected to what you think is your local coffee shop's WiFi surely doesn't require hacking your server.

[pbatard]

You fail to explain how having Windows properly identifying that the signature could not be validated (as opposed to your CVE claim that implies it will be) as well as telling you that you shouldn't run the software counts as a security vulnerability.

If that is a vulnerability, then I sure wish all vulnerabilities also announced themselves as explicitly as this, coz that would make security a whole lot easier.

[wdormann]

Software should ideally update itself securely, and not rely on the end user to understand the nuances of code signing. Even with a valid signature, your update mechanism that you believe to be secure will warn the user with a yellow exclamation point saying "... this file type can potentially harm your computer. Only run software from publishers you trust"

Relying on users to remember subtle wording differences and always make the proper decision based on them just doesn't work in the real world.

As with any software vendor, it's your right to choose not to fix a vulnerability. The CERT/CC is here to make sure that software users are informed either way.

[pbatard]

As I was expecting, here we go with "ideally" and end-users being the actual vulnerability (as opposed to the software, which, again, and exactly as claimed, does properly report that the signature was invalid on self-signed binaries). Care to log a CVE for end-user behaviour being the only source of the actual potential vulnerability here?

it's your right to choose not to fix a vulnerability.

I have no issue fixing vulnerabilities. The only problem is that, as opposed to what you are claiming, this isn't one if, as we have demonstrated, the software is properly alerting the user about any unwanted code being potentially run. Or are you now trying to blame Windows developers for choices that Microsoft made about how they display benign and non-benign alerts, and over which they have exactly zero control? If you care that much about it, how about you log a CVE against Microsoft Windows for misleading prompts. Surely that would help a lot more of the users you seem to be so concerned about....

Also, you must have failed to read the part in my original reply where I pointed you to the recent issue where someone raised the same concern, and where I stated:

Besides the http workaround is mostly aimed at being temporary, while I release the last ever version of Rufus that'll be compatible with XP and Vista (since XP can't access the downloads through https at all, no matter what). After 2.17, I will switch back to using https.

Way to overreact about something that was always planned to become a non-issue in a couple of months... and that was also non issue up to 2.15 (since the switch from HTTPS to HTTP was something that got introduced in 2.16 as a last gesture of good will for XP users).

The CERT/CC is here make sure that software users are informed either way.

mis informed, rather, I would say, since you clearly fail to mention that there exists a very explicit alert about any arbitrary code execution attempt, and have to invoke users ignoring a non-benign warning to try to prove your point.

[pbatard]

Still waiting for that cert.org vulnerability report against Microsoft Windows for what you clearly consider to be misleading prompts... Or should I conclude instead that cert.org employees use their position of power only to go after the smaller fish?

I mean it's not like the prompt confusion you had to resort to invoking as the only vulnerability in this whole discussion (coz, after all you said, you have to concede that if Microsoft had decided not to display a prompt for applications with a fully validated certified signature, and only show one when on validation failure, you wouldn't have much of an issue with the way Rufus updates over HTTP) goes way beyond HTTP vs HTTPS, and getting Microsoft to improve on this could actually help millions of Windows users...

If you do log a vulnerability against Microsoft's misleading prompts, and get Redmond to make them more user-friendly on signature validation, I promise you won't have to take to twitter to complain about that thankless job of yours, as I'll be the first in line to thank you for doing your job. 😄

[rugk]

TL;DR: Rufus has a HTTP download and unfinished signature check allowing users to bypass any security and infect their device with one click.

So maybe this issue is not so much about HTTP (although HTTPS would clearly solve/mitigate the problem), but about the broken signature check from a UX perspective.

To explain it in an image, because an image says more than thousand words, here is what the average John Doe sees (modified screenshot from one comment before):

[pbatard]

Rufus has a HTTP download

Yes, for a couple more releases so that XP users can get the last ever update, because the default XP internet APIs are too old to connect to a server that uses modern SSL settings. And on that subject, I think I may have confused the check for latest version data, which was using HTTPS until 2.15, and got switched to HTTP in 2.16 because I realized that XP users could no longer receive updates, and the actual binary download, whose protocol is decided by the version data (https://rufus.akeo.ie/Rufus_win.ver) which has been using HTTP since the beginning, as I ran into an issue the day I tried to switch to HTTPS, which I never got around to find time to fix (but which I'm planning to after XP is out).

and unfinished signature check

I don't think so. We're calling on the one Windows API that is intended to fully validate digital signature (and is actually what generates the prompts - the prompts we are talking about are not controlled by Rufus). Not sure what else we could add to "finish" the signature check, but I'm open to advice.

So maybe this issue is not so much about HTTP but about the broken signature check from a UX perspective.

I would tend to agree with that, and point out once more that the prompts are generated by Windows itself when invoking WinVerifyTrust(). If it were up to me, I'd rather have control over which prompts get displayed, so that when the signature is fully validated, and the name matches what we expect, we don't get a prompt but an AOK, and so that if the signature doesn't validate, we also don't get a prompt allowing the users to still run the binary and just an error code, but we're tied to the default Windows API & UI behaviours, and I have never seen it as an issue requiring to need to deviate resources and reinvent the regular Windows signature validation wheel.

Ergo, I'd rather that a vulnerability was logged against Microsoft Windows, for misleading UI prompts, because otherwise, I'm being asked to replace a single tried and tested API call that does exactly what it is being asked to do (alert users if a binary is not digitally signed with a trusted Authenticode signature) with something that may require a lot more work and introduce more vulnerabilities than it fixes.

In other words, as far as I'm concerned, the issue is with how the Windows APIs decided to make a benign and not-benign-at-all prompt look the same for users. And, even if that happens as part of the update process, that is not something Rufus has any control of.

[pbatard]

Following up on this, and looking further into WINTRUST_DATA, I guess there does exist some options that I forgot (WTD_UI), that bring control over which prompt are being displayed. As per the code, I decided to use WTD_UI_ALL at the time, because I probably didn't see much harm in doing that, but I probably should have picked one of the other options. At any rate, this still has little to do with the HTTP vs HTTPS debate that prompted this whole discussion.

I guess I can try to play with these to make the update process less reliant on users actually reading prompts. But since this issue appears to have attracted a lot of attention, I'd also like to hear opinions as to what kind of behaviour people would want to vote for (i.e. which prompts to display).

[rugk]

Also I don't know the API used, but does not it basically validate all "code signing certificates"? So anyone could at least inject calc.exe as it is, as I assume it is signed by Microsoft?
And BTW, also malware can get code signing certs, it depends on a PKI similar to SSL/TLS (because you spoke of three-letter agencies…) and I think up-to Windows 7 (at least before a specific update) SHA-1 (not good) was used for code signing certs, so this whole system is a bit flawed. PGP/GPG or so would be a better verification.

Back to UX: Needed kind of behavior: On error, abort. Only continue on successful verification. Easy.

BTW, there are more bad things, which can happen when updating. See https://theupdateframework.github.io/ for a real secure update mechanism.

[pbatard]

but does not it basically validate all "code signing certificates"?

Nope. It does the full Authenticode validation, which means a self-signed certificate can only validate if the Windows user has already added it to their Trusted Root/Trusted Plublishers store (i.e. if another, usually user-driven separate action has taken place).
If you follow that logic, knowing that this is not something that can be enacted stealthily during the update process, it is not possible to replace an HTTP download with one that is self-signed by "Akeo Consulting", without getting the prompt that tells you that the signature is invalid.

This is actually the part where the cert report is blatantly misleading, as it states that the "lack of CA checking allows the use of a self-signed certificate.", as if this can happen without the user being explicitly notified about a self-certificate being used.

And BTW, also malware can get code signing certs

I'm well aware of this. This is what revocation is for (and why we enforce revocation checks during the signature update). The whole trust chain also requires that checks for bad apples are done in real-time. The expectation however is that most CAs take security seriously and that the ones that don't are identified, so that, as opposed to what the Cert report says, when Rufus does validate the whole trust chain as part of the signature validation, and gets to a dodgy root CA that was revoked, it does report that the signature is invalid.

SHA-1 (not good)

Yup, I switched to using an SHA-256 based signature as soon as the potential depreciation of SHA-1 was announced. Unless you have knowledge that I don't, I don't believe that SHA-256 signatures are "flawed" just yet... At the very least, the signature validation from Rufus shouldn't be, as it has been using SHA-256 for quite some time (on platforms that support it, which includes Windows 7).

PGP/GPG or so would be a better verification.

I don't think so. Again, unless you know of an SHA-256 flaw that security experts are not aware of (or haven't published), SHA-256 should be more than adequate for digital signatures. Of course, this creates a bit of an issue for XP and Vista (since they don't natively support SHA-256 validation, or at least that wasn't the case last time I tried), which is the precise reason I'm gonna drop these platforms when my other SHA-1 code signing certificate expires in a few weeks.

Needed kind of behavior: On error, abort. Only continue on successful verification. Easy.

So, a vote for no UI prompts at all. That's fine with me.

See https://theupdateframework.github.io/ for a real secure update mechanism.

I like that one of their point is "The framework must be secure to use in environments that lack support for SSL (TLS)" which is pretty much my point: You do NOT absolutely need SSL to provide secure software updates, and great care must be taken not to fault a software update mechanism simply because it doesn't use SSL.

[MTWomg]

How many experts need to say 'You must use SSL' before you get it? What you think is irrelevant; you are wrong. Use SSL. It's not a big deal. Swallow your pride, admit your mistake, switch to a modern secure updating system and move on.

The point about Windows XP is silly. Software should not support an operating system Microsoft no longer supports. This is obvious to everyone other than you.

No, SSL in and of itself is not enough to solve the problem, but the problem cannot be solved without SSL.

[riking]

Describe the problem before describing the solution.

The update mechanism must:

• reject unsigned and improperly signed executables
• reject random Microsoft-signed executables
• reject executables signed by Authenticode certificates not controlled by you
• allow for CA updates
• work on Windows XP SP3 and newer
• not invite the user to make bad decisions
• provide user with recovery in case of no-updates-ever type failure

Nice to have properties:

• tolerate network failures
• comprehensible error messages
• not cause warning fatigue
• do not allow an adversary to null the update check

So: "Work on Windows XP and newer" means that "use SSL for every step" is, unfortunately, not an option until XP is dropped.

With that stated.
My suggested changes:

• Do not allow click-through to use the executable. Throw away the download in the case of any error.
  • This error should be replaced with Downloaded file is invalid or corrupted, please check your network connection. (Details: Wrong subject "Nortel Networks")
  • This error should be replaced with Downloaded file is invalid or corrupted, please check your network connection. (Details: Chain does not validate)
  • Of course, you do not need to use my exact wording, but you get the idea. Reformat the "no signature" error message to fit the format you choose.
• If update repeatedly fails, recommend that user manually use their browser to download the new version instead of allowing them to use the downloaded file. If the browser's security is worse, it's Not Your Problem anymore.

---

The expectation however is that most CAs take security seriously and that the ones that don't are identified

Unfortunately, this is not the case. There is no proactive policing taking place for code signing certificates, so the CAs that do not take security seriously are not being identified. And when the mistakes are small and the CA is "too big to fail" cough...

[pbatard]

reject executables signed by Authenticode certificates not controlled by you

Which I'm doing in part by checking the name of the signing cert. I can't hardcode a check to the hash of any certificate along the chain, because I consider that I may switch CAs when my current certificate expires, and I want the ability for a Rufus binary signed with a signature issued by CA X to not report an error when validating a new official version of a Rufus binary signed with a signature issued by CA Y.

I'm open to suggestions here, but I don't think there exists a good solution to the problem of rejecting future Authenticode certificates that I don't know any property of, except their name. Can't use self-signed certs that are going to be under my control, because they won't be trusted on first use in Windows, so, whereas other update processes may have some more flexibility here, I have to go through through using commercial Authenticode ones, and take into account the fact that they are going to expire while users are still relying on Rufus to download updates.

And again, I must stress that any self-signed certificate (including one claiming to be from "Akeo Consulting") will produce a very explicit prompt about the signature being invalid, which, due to Microsoft unfortunate UI choices, may be hastily dismissed as a benign prompt, and I expect that, as soon as a switch to using WTD_UI_NONE, these self-signed certificate will simply return an error, without any UI prompt, thereby solving the issue of users deciding to run an unsigned app, despite an explicit prompt advising them against it.

not invite the user to make bad decisions

Expected to be solved once prompts are removed with WTD_UI_NONE. To be honest, I think I probably went with WTD_UI_ALL because I was eager to see the signature validation process in action and wanted to give users like myself an opportunity to validate the name of the signer, since the automated checks on the signer name were introduced some time later, and I explicitly mention on the website to confirm the digital signature name. In retrospect, I should have switched to WTD_UI_NONE once I had the extra checks in place, but that didn't happen.

Throw away the download in the case of any error.

Again, this will be solved once the prompts are disabled altogether. At this stage, I will control the error chain so I will be able to throw whatever error message seems most appropriate.
For the record, I don't think a validation that explicitly detected that the signer doesn't bear the expected name can be summarily dismissed as "invalid or corrupted file". However, in case my CA renewal doesn't work as planned (CA forces the renewal under a name that isn't the one I hardcoded for validation — I had loads of trouble getting them to accept to use "Akeo Consulting" last time around), I think I will prefer to keep the more explicit:

Now, if the file is not digitally signed, or the signature validation fails, I can go with your suggestion (and will delete the download). But I hope you can appreciate that there's a little bit of preparing for a future process that may not unfold as planned to be taken into account.

There is no proactive policing taking place for code signing certificates

Then there is something rotten in the realm of code signing certificates.

Still, Microsoft does seem to update its Trusted Root CAs and Trusted Publishers on a regular basis through Windows Update (even if it's hard to tell which of these are actually relevant for Code Signing), and I would surmise that, until they have forced everyone to migrate to the Windows Store, it is in their interest to identify and remove bad apples.

[riking]

Then there is something rotten in the realm of code signing certificates.

Indeed. Not going to talk about it here.

I can't hardcode a check to the hash of any certificate along the chain, because I consider that I may switch CAs when my current certificate expires, and I want the ability for a Rufus binary signed with a signature issued by CA X to not report an error when validating a new official version of a Rufus binary signed with a signature issued by CA Y.
I'm open to suggestions here, but I don't think there exists a good solution to the problem of rejecting future Authenticode certificates that I don't know any property of, except their name.

If I remember correctly, what you do is (1) renew in advance (2) create & distribute an update that adds the new certificate details (3) After an update or two, switch to the new certificate (4) Old clients must first update to the last version signed with the old certificates, then they can update to the last version signed with the new certificates.

[rugk]

Which I'm doing in part by checking the name of the signing cert.

Insecure. I think the name field is just a field you can choose arbitrarily when issuing code signing certs, so this check does not help. Or, at least, when self-signing them.
Only a hash check would really help here for sure. Hardcode the root cert, or whatever…

I think we all agreed on the UX changes needed. (download throw away; prompts)

I think I will prefer to keep the more explicit:

Do whatever you want, just don't allow the user to click-through. (i.e. no "Yes, please do something insecure!" button.)

But to get back to a big point:

Of course, this creates a bit of an issue for XP and Vista[…] which is the precise reason I'm gonna drop these platforms when my other SHA-1 code signing certificate expires in a few weeks

Hey, so when you drop XP support anyway, then you can also use HTTPS. (BTW no one prevents you from setting up a subdomain with a slightly weaker TLS config for older platforms.) And using HTTPS is always a good idea even if you do not rely on it for security, as it is just the easiest solution and a basic thing for security here.
You see how complex that thing can get (also how the updateframework does it) and how many errors one can make in this issue, that's why HTTPS eases the whole thing and simplicity is almost always good for security.
And, of course, you can (and probably should) use your signature verification mechanism even when using HTTPS.

[pbatard]

@MTWomg,

The point about Windows XP is silly. Software should not support an operating system Microsoft no longer supports. This is obvious to everyone other than you.

Did it ever occur to you that Rufus is software that many people use to migrate to a newer version of Windows (or ditch Windows altogether and move to Linux)?

I'll leave you to draw your own conclusions as to why a developer might decide, against their will, to overextend application support for an obsolete platform, especially one that they hate with a passion (cc758f5)...

@riking,

If I remember correctly, what you do is (1) renew in advance (2) create an update that adds the new certificate details (3) Old clients must first update to the last version signed with the old certificates, then they can update to the last version signed with the new certificates.

Pretty cumbersome, especially for a standalone executable with no installer and that tries to store as little data as possible on the system. And if working with Authenticode certificates, this requires having enough overlap time to have 2 releases... Can't say I'm a fan of the diminished user-experience, especially considering that the vast majority of Rufus usage is done in a one-of fashion, with many months between sessions... But I'll give it some more thought.

@rugk

I think the name field is just a field you can choose arbitrarily when issuing code signing certs

Tell that to my current CA! I actually tried to use "Akeo Systems" instead of "Akeo Consulting" for my current certificate, but they would have none of it. And even "Akeo Consulting" was a challenge, as they weren't too happy this wasn't a formal company that's registered in well known indexes. So, even if it's difficult to draw a general conclusion from a single experience, I have to firmly disagree with your statement.

Hey, so when you drop XP support anyway, then you can also use HTTPS.

Yeah. I had only one release planned that would still use HTTP, which I actually made pretty explicitly clear on my first reply. But it seems a lot of people in this thread decided, in lieu of actual Rufus users, whether XP and Vista compatibility was still useful to have for users who want to migrate away from these systems (stats from the update check for this month show that there is still an unhealthy 1.5% of users that were running Rufus on an internet-connected XP), or failed to comprehend that the decision not to use HTTPS was actually a compromise that I wasn't that keen to make in the first place...

I guess, since I don't think cert.org is going to alter what I consider to be a very biased and misrepresentative report, I may actually release 2.17 early with the WTD_UI_NONE change, that'll still download updates through HTTP but may prompt security conscious people to look at the "vulnerability" through a different lens, and then release one final XP and Vista compatible 2.18 shortly before my SHA-1 cert expires (in about 2 months), before switching everything to HTTPS.

[MTWomg]

No one running XP on a real computer is able (in terms of specs) or technologically proficient enough to be using Rufus. We are talking about people using VMs. Fuck them. Make a special version of Rufus that only runs on XP/Server 2003 if you want to support them.

[pbatard]

Yes, or switch between HTTPS and HTTP according Windows version, which I also thought about when SSL started to be an issue on these old platforms. Still, that's a problem that will naturally resolve itself in 2 months time, which, as much as people may scream about it, I don't consider that big a deal once the UI issue has been addressed.

[MTWomg]

You are doing a massive disservice to your users, many of whom are putting their corporate networks at risk by using your software. It's real cool that you just disregard what the experts tell you and do your own thing. It's a mature and smart move, and it's just the type of behavior I look for when choosing software.

[Itaros]

It looks like this is a drama about actually multiple points of problem. What I can say: I like the fact that application gives a right to user to bypass signature check by saying: "Yeah, execute it anyway" because circumstances may differ and non-signed binary(or signed as other authority) intentionally might have it own merit. Sometimes, for example, it is heartbreaking when software reaches end of life and there tons of hardcoded safeguards which forbid its use beyond its time. It is not that prominent for update feature, but I think it is about a trend of taking away user responsibility and flexibility of entire application to provide more security by building walls like russia banning VPN, because terrorists might use it. What a joke... In regards to HTTPS vs HTTP can't say much tbh as I don't know how that might help.

Addendum: I doubt Rufus is made for 'average Joe' despite being an awesome application which simplifies quite a daunting task. I can't imagine it being used by accountant in corporate environment tbh xD

[21341r]

I'm well aware of this. This is what revocation is for (and why we enforce revocation checks during the signature update).

I think you misunderstand the purpose of code signing, it isn't to endorse software but rather to verify it's origin. Malware certificates usually only get revoked because they're stolen.

[pbatard]

I think you're trying to put words in my mouth that I didn't say, and you are also ignoring my user experience, part of which I described, in trying (and failing) to get Authenticode credentials with a name of my choosing. For people who may not be familiar with the process of getting an Authenticode certificate, and since I have now gone through both processes multiple times, I will say that the background check for the delivery of Authenticode cert is a lot more extensive than the one for an SSL cert.

Also, my expectation is that if someone manages to get a genuine Authenticode certificate issued to "Akeo Consulting", which they attempt to use to impersonate the signer of my software, and provided their CA is not rogue, I will be able to contact their CA to get it revoked due to security concerns that a CA should be very receptive to. In other words, revocation mechanisms should be able to be invoked to help contain the threat. If needed, I could probably also rely on litigation relating to global business names, since "Akeo Consulting" is a registered company in the Republic Of Ireland. At any rate, if this is the argument, I will dispute the idea that a non-rogue CA will be unreceptive to taking measures against a certificate they issued, even if it wasn't stolen, if it can be demonstrated that that certificate was used for impersonation with malicious intent.

And if the CA is rogue, then I would try to contact Microsoft (the entity in control of Authenticode) to let them know that the CA refused to revoke a certificate that was used to impersonate a different entity with malicious intent, again with the expectation that, if I am not the only person to report this (which is likely if the CA is rogue), Microsoft will take action which may go as far as flagging this specific CA as untrusted in n upcoming Windows Update.

Considering that we've seen rogue SSL CAs being deprecated in Chrome and Firefox (here and here), I have reasons to expect that, if they have to, Microsoft may very well do the same thing for rogue code signing CAs in Windows (noting that, if someone wants to be pedantic, this kind of wholesale rogue CA "revocation" is completely different from the regular revocation mechanism we mentioned earlier).

But to get back to punctual revocation, and to reiterate my point, I disagree that a non-Rogue CA will only revoke a certificate if stolen, if they are presented with a verifiable case of abuse of identity for nefarious purposes. And in that case, a signature verification, with revocation check, does go further than verifying the software's origin. Or, since you are trying to put words in my mouth that I didn't say about "endorsing software", I would rather say that the whole point is to provide some level of confidence (to end users of the software) that the signer of the software was established trustworthy at one stage, and, to the current CA's knowledge (revocation), that this initial trustworthiness still applies.

Of course, this trustworthiness can only go as far, but then we're talking about flaws with the whole code signing model which is a completely different discussion.

[atarii]

There is a way to exploit the lack of HTTPS on the update mechanism which hasn’t been mentioned yet.

tl;dr an attacker could force a downgrade to an older version of Rufus first which doesn’t do signature validation on updates.

Rufus versions >1.5.0 are signed by Akeo Consulting and as mentioned above, there is a check to only run updates that validate against their certificate chain. In the ChangeLog for version 2.5 it mentions “Add digital signature check on update downloads” - so versions older than 2.5 have a no certificate check on the update mechanism. Therefore an attacker could force the update to actually downgrade to an older version (one that is >1.5.0 and <2.5); for example version 2.4 works. Then when that older version runs and does an update check, the attacker takes advantage of the missing update binary verification and sends a malicious binary instead.

Steps to reproduce:

1. User runs latest Rufus (2.16 at time of writing) and performs an update check (or waits for daily one)
2. Attacker intercepts request (via network spoofing methods not needed to be mentioned here)
3. Attacker responds with a fake update response, returning valid rufus-2.4.exe from official website
4. User allows update process to complete, effectively downgrading them to rufus-2.4
5. Once rufus-2.4 launches, this version performs it's update check
6. Attacker intercepts request again
7. Attacker responds with a fake update response, returning any malicious binary
8. Checks are not performed in the 2.4 version Rufus and so it successfully runs the malicious binary

I’ve recorded a demo of this here, first downgrading to 2.4 and then returning a simple helloworld MessageBox executable as the final payload:

[pbatard]

Well, why I can see the point of users confusing the valid and invalid signature prompts, and I applaud the effort, I think the idea that someone will not notice that the title of their application window goes from 2.16 to 2.4 to something else, and through 2 successive updates is a bit far fetched.

Or are we simply going to add yet another condition about users not paying attention to application behaviour at all? This goes way beyond choosing to ignore relatively common prompts...

Since I'm way beyond trying to make any friends with cold facts on this thread, let me say this to pre-empt the upcoming flow of recrimination: if you all want to assert that Rufus users are stupid, to try to justify an exploit that I estimate tenuous at best, have a go at it and see how far that takes you...

[MTWomg]

You are subjecting your users to needless risk and are doing so solely out of stubbornness. Do you not see how childish your behavior is? It’s not about smart or dumb, it’s about reducing risk by making trustworthy software.

[pbatard]

Also, I have to question this point:

Once rufus-2.4 launches, this version performs it's update check

If I recall correctly, unless the user triggers the second update check manually, and because the timestamp of the last update check was stored in the registry, this new update check will not occur for another 24 hours at best, and your demo effectively shows you performing the update checks manually.

As per the update code Rufus will read the update interval setting (which can not be set to less than 24 hours through the UI), then the last update timestamp, which, if you went through the 2.4 downgrade, is stored before the downloaded application is launched.

So, logically, once 2.4 is launched, the update check should not automatically trigger for another 24 hours, and the exploit requires active user participation with the user having to manually check for updates right after they downgraded to 2.4.

Or have you actually observed the automatic behaviour you described with both update checks being launched one after the other without user intervention? Because if not, then you are trying to misrepresent the behaviour of the application.

[DeathsPirate]

So an attacker would have to wait a whole 24 hours for full compromise? I'm pretty sure they wouldn't complain. This is a vulnerability that is putting users unnecessarily at risk. I understand that you're protective of your project but you need to listen to advice from SMEs when they try to help you.

[pbatard]

So an attacker would have to wait a whole 24 hours for full compromise?

That's the current assessment.

I'm pretty sure they wouldn't complain.

Yes, but is is realistic? Is there a precedent of a CVE that actively requires the user to remain under the attacker's network control for 24 hours or more for the exploit to trigger? Or do the CVE people also take into consideration the amount of time that needs to elapse before an exploit can be triggered as a mitigation factor?

[MTWomg]

Is this a joke? Of course it’s realistic, and you aren’t an infosec professional so you are in no position to make that call. Your role is to fix vulns, not to question the practically of exploitation.

…

Sent from my iPhone On Aug 30, 2017, at 3:11 PM, Pete Batard <notifications@github.com> wrote: So an attacker would have to wait a whole 24 hours for full compromise? That's the current assessment. I'm pretty sure they wouldn't complain. Yes, but is is realistic? Is there a precedent of a CVE that actively requires the user to remain under the attacker's network control for 24 hours or more for the exploit to trigger? Or do the CVE people also take into consideration the amount of time that needs to elapse before an exploit can be triggered as a mitigation factor? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1009 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjYeqZYWXt_bsKOF-TG1l0wnQQ3ecE2ks5sdbPVgaJpZM4PEtDh> .

[DeathsPirate]

Yes, but is is realistic?

Yes, it's very realistic. If an attacker has a way to exploit a system ... even if he had to wait a month ... they would.

[ikehoff]

It only takes one small hole to sink a ship, given enough time. An attacker will wait if the jewels are worth it.

As the developer, you have the unique opportunity to fix this hole and be a savior. My recommendation is to turn on HTTPS immediately and recommend XP users run another version of Rufus which utilizes HTTP. Perhaps you branch Rufus now leaving this branch as the perpetual XP version while the master branch continues on with HTTPS?

Lots of software vendors have multiple versions for different Operating Systems.

[pbatard]

Okay, you've made your point, even though I was asking about actual CVEs and what counts as mitigation factors (especially knowing that, due to the purpose of the application, recurring usage of Rufus is the exception rather than the norm).

I will take all that was discussed above in consideration, and lock the thread.

[pbatard]

Closed per commit c3c39f7.

Note: Before you grab pitchforks on this issue now being closed, please make sure you read the end of the commit message for the above commit, knowing that I expect to have to spend some time laying some non-technical groundwork before I can take the second vulnerability scenario, and HTTP vs HTTPS, further.