Opened 11 years ago
Closed 11 years ago
#8863 closed enhancement (duplicate)
plugin code downloading and updating is not secured (most importantly: authenticated) at all
Reported by: | pendluuum | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | tested |
Keywords: | security https | Cc: |
Description
plugin downloading and updating is not secured at all ... at least it is not obvious to me if there is a check currently (e.g. gpg signature verification of downloaded plugin packages).
The plugin update URLs (the list itself and the .jar URLs in the list) should be https by default (loading to-be-executed code over an unsecured connection is no good idea/bad practise, greetings to NSA and the authorities in China) and the self-signed JOSM certificate be accepted by hardcoding a whitelist exception for it it in the JOSM code.
The plugin URLs seem to always point to svn.openstreetmap.org which currently does not seem to support https - that is to be fixed upstream first.
If downloading via https fails for some reason (maybe a new certificate was issued after the JOSM version was released) a dialog should offer to download via unsecured http (selections: "this time only" or "everytime"). This ("everytime") setting should be accessible via a checkbox in Settings/plugins/"edit plugin sources". There also should be checkboxes (checked per default) named "accept the josm.openstreetmap.de certificate (SHA1 …FD:61:3d)" and "accept the svn.openstreetmap.de certificate (SHA1 …xx:xx:xx)".
If all of that is regarded as not relevant by the JOSM programmers then at least the user of JOSM plugins should be informed about that insecure practice when he first downloads a plugin.
Attachments (0)
Change History (4)
comment:1 by , 11 years ago
Component: | Plugin → Core |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Type: | defect → enhancement |
comment:2 by , 11 years ago
Oh,I did not think that the situation is that bad. ;-) Please note that bug reports are no personal attack on volunteer programmers like you but try to help with a problem! :-) Throwing a WONTFIX, CLOSED and some religious swear words at my head is not nice.
Sorry, but you miss the point completely. I try again: The issue is that the transmission between the "own server" and "trusted locations" is not checked to be really from the JOSM-team / authentic (and not modified). That means that every station between the server and the user's computer (secret services, ISP, attackers in the same LAN, ...) can alter the files downloaded. These downloaded files will then be executed, so all those attackers can insert (malicious) code which will run with the JOSM privileges on the user's system. That is how the trojan "flame" infected target systems. With JOSM running on a computer (and trying to update plugins) the attacker would not even have to fake a certificate because there is none. Code signing or authenticated transmission are popular in software update scenarios to prevent altering during transport to the user or faking updates.
Yes, if you have no enemies and you don't live in China or Iran or, or, or a person spied upon by the NSA ... yes, then that issue may sound totally crazy and negligible.
comment:3 by , 11 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Summary: | plugin code downloading and updating is not secured at all → plugin code downloading and updating is not secured (most importantly: authenticated) at all |
comment:4 by , 11 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
Closed as duplicate of #9778.
For Christ's sake, we are just downloading a public text file from our own server and some jars from trusted locations. There is no personal information involved, there's no reason to enforce an HTTPS connection here. Keep in mind we're not building a web browser but a dedicated map editor...