A software named evilgrade demonstrated the vulnerable auto-upgrade issue :
Generic UPdater (another GPL project, written by me) is used by Notepad++ to do its auto-update :
Obviously, Notepad++ will have the security issue due to GUP.
If anyone have idea to enhance GUP security issue, please let me know.
Digitally sign releases...
I guess you're talking about to sign the binary, then release the signed binary with its public key.
Embedding the public key in a signed executable only prevents the executable from being modified.
An attacker could simply supply a different executable with his own key embedded in it.
So digital sign release is not a solution for Man-in-the-middle attack issue.
Well, you distribute the pubkey with Notepad++ - if a user manages to get an un-exploited version once, the pubkey there keeps him safe from that point on.
It's Generic UPdater (GUP) who does the whole update job but not notepad++ :
Notepad++ just launches GUP,
GUP checks on a specific url (defined in a xml file) to see if there's a new version available.
if yes, it gets full url to download the install package, then execute the installer.
So afaics, signing Notepad++ and distribute the public key with it won't keep user from man-in-the-middle attack.
Or I do misunderstand you completely?
Haven't looked into GUP, sorry, but it was my impression that it gets it's configuration (server to contact, what more?) from a *local* .xml file? Your pubkey (you could either use one per-project, or just a single "Don Ho" key) would be stored in the .xml, and GUP would be updated to use this.
Also, requiring HTTPS:// connections to the update server could help mitigate the problem. But then you do face the dilemma of either getting a CA-signed cert ($$$) or using a self-signed key (which seems suspicious to most people). And if you don't have server id fingerprint in the .xml file, it doesn't help much (blindly trusting certs just because they're CA-signed is a bad idea).
snemarch has a good idea. Delivering the public key in the xml along with the download instructions will work. Just sign the deliverable with the private key when you create it, then after GUP downloads it, it decrypts the deliverable with the public key from the xml instructions. If the decryption fails, GUP knows that the deliverable was corrupted.
The only way around this is to deliver false instructions in the xml in the first place.
To mitigate this, you could also post your public key on the website, and provide a key verification mechanism within GUP. Still not foolproof, but it would be that much harder for the bad guy to circumvent.
Of course, this is a lot of work for a DNS attack that's supposed to be 80% rectified within the next week or so. So maybe just talk to your SourceForge rep's and make sure that their DNS provider is patched.
Good luck with a great product,
GUP shouldn't rely on pubkey posted on web site - if DNS cache has been poisoned, attacker has control of what GUP sees there :). But it would probably be a good idea put the pubkey on some keyserver that has authenticity in place.
Don't simply encrypt/decrypt the distributed file, *sigh* it. Probably a bit cpu-intensive doing pubkey decryption of something as (relatively) big as a NP++ release, anyway ;). Don't roll your own, use recognized and test libraries. And get somebody good with crypto to review the scheme before launching, there's a lot of pitfalls. I'm not claiming to be a crypto expert here, I just hope I know enough to avoid the most common pitfalls.
And as I understand the exploit, it's not really about sourceforge's nameservers being patched. You find out which nameservers your *victim* are using, then you poison those. In case you find a big ISP with unpatched DNS, you have a lot of potential victims.
Well, I would like to say that I hope you guys will find solution to this problem. My company doesn't want me to use Notepad++ anymore because of that.
"https://" solution costs. Even I get one CA-signed certificate free, I am not sure that I can deploy a "https://" site on sourceforge.
OTOH, distribute only signed installer package by a certificate, then keep always the same public key on the side of GUP to check the signature of installer is a good idea - the public key hard coded in GUP to make sure this public key won't be replaced by any malware.
Thank you for the hint, Sune.
Yes, HTTPS:// is costly in many ways, and wouldn't even be a solution by itself, only a mitigating factor. And I doubt you'd be able to throw your own SSL certs on SF :)
Hard-coding a pubkey in GUP would make it less generic, since only one person would be able to sign. Imho you really need the certs in the program .xml update files.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.