Modify

Opened 2 weeks ago

Last modified 13 days ago

#15624 new enhancement

It would be far too easy to hijack a plugin with malicious code

Reported by: ris Owned by: team
Priority: normal Milestone:
Component: Plugin Version:
Keywords: plugin jar signing certificate tofu security Cc:

Description

(apologies if there is already a bug on this subject, I couldn't find it)

Right now, all a malicious actor would have to do is replace a link to a relatively popular plugin on https://josm.openstreetmap.de/wiki/PluginsSource and potentially thousands of users would have their josm "automatically upgrade" to it. Possibly the change could be disguised by just using a very-similarly-named github user.

I see this as quite a real problem and could be something that harms JOSM adoption, even if it doesn't ever happen to get exploited. I suspect it might not pass an organization's thorough IT audit and could preclude its use in large organizations or government bodies. Just this month I was proposing to an NGO implementing some tool they wanted as a JOSM plugin, and as a professional I really have to consider whether I would want to expose their systems to this risk.

Clearly, following java's trodden-path of jar signing and requiring all plugin authors to have jar-signing-capable PKI certificates would be a significant burden (or would it if you were able to be your own pseudo-CA and bundle your own root certificate with josm?), but it might also be possible to use java's jar-signing mechanism to implement a form of TOFU which would go a long way towards settling the hijacking worry (josm would show a warning if trying to upgrade a plugin that was signed with a different key?).

What are peoples' thoughts on this?

Attachments (0)

Change History (9)

comment:1 Changed 2 weeks ago by Don-vip

This already almost happened once with plugin "no more mapping". But this was only a prank.

Putting in place a PKI/signing infrastructure would be overkill. We rely on the good faith of the community.

Yet I agree this is a risk in a professional environment. What we could do to mitigate it is rely on the notion of "external plugin". We could offer a security mechanism on client side which blocks any plugin which is, or suddenly becomes, external (i.e coming form a different location than svn.openstreetmap.org and github.com/JOSM. The list is currently customizable I think, so you could also add private company repositories).

It should not be very difficult, maybe you would be interested in bringing in this feature?

Last edited 2 weeks ago by Don-vip (previous) (diff)

comment:2 Changed 2 weeks ago by Don-vip

Keywords: security added
Type: defectenhancement

comment:3 Changed 2 weeks ago by ris

I'd be far more interested in adding TOFU support for external plugins, as e.g. personally I have no immediate plans to de-externalize my plugin(s). Indeed, "internal" plugins could probably skip this check.

The example "popular" plugin I had in mind as a target was Mapillary, still being an external plugin.

comment:4 in reply to:  3 Changed 2 weeks ago by Don-vip

Replying to ris:

I'd be far more interested in adding TOFU support for external plugins

Had to look what TOFU means, but yes, sounds nice :)

comment:5 Changed 13 days ago by stoecker

In this scenario TOFU should be implemented in the server side checks dropping a plugin entry from the list when irregularities are detected.

But how do you want to introduce a secret on the plugin build side? Most development scenarios which we have ATM prevent this.

comment:6 Changed 13 days ago by ris

In this scenario TOFU should be implemented in the server side checks dropping a plugin entry from the list when irregularities are detected.

That's interesting yeah I had been thinking around this area, but was leaning on the check being done on the user side to give them the opportunity to ignore a mismatch. One of the drawbacks of TOFU is when people lose their keys or want to switch them, it's going to trigger an alert - if that causes a hard failure, it would be ... bad. I guess you've also got to consider the administrative burden of doing things server side: if a key doesn't check out, is it now a chore one of us has to perform to go and contact that author and verify that it really is a genuine switch? What if people are always losing their keys?

Certainly a server-side check would be useful, whether or not there was also an in-JOSM check.

how do you want to introduce a secret on the plugin build side? Most development scenarios which we have ATM prevent this.

Not sure what you mean by this. The jdk comes with tools for key generation and signing...?

comment:7 in reply to:  6 Changed 13 days ago by stoecker

how do you want to introduce a secret on the plugin build side? Most development scenarios which we have ATM prevent this.

Not sure what you mean by this. The jdk comes with tools for key generation and signing...?

A secret must be secret. That conflicts with open source development models. Plugin developers are groups of people and also change relatively frequently. I fear that code signing actually is not really a really good way to solve the security issue. While in theory it can solve the malicious code problem in praxis I fear it is still extremely easy to introduce bad code if nobody watches.

JOSM server code could store a list of valid certs (also self-signed, officials are too expensive) per plugin which overcomes the "one valid cert" problem, so each developer can have an own cert. If looking at the troubles to get plugins update deprecated code I'm not convinced that code signing will actually improve the situation except for a minority of plugins (yours?). But it probably also does no harm.

Two ways could be:

  • We make a JOSM wiki page containing signing information (write protected for anybody except admins)
  • a)
    • The "/plugins" entry transports this additional signing information
    • JOSM code checks if signing is ok when downloading updates
  • b)
    • The server side code removes the entry for invalid signing.
  • c)
    • a and b

Question is: Is it worth the effort?

comment:8 Changed 13 days ago by ris

Right, so, a lot of plugins are group-maintained and don't have a particular "owner" as such. That would indeed make TOFU painful.

You two solutions both look viable, but I've got to note that they are slightly like building a homebrew CA :) It would probably be important too to capture the list of plugins a certificate holder is authorized to make new releases for.

Worth the effort? If nobody else is interested, it's something I'd probably be interested in taking on.

comment:9 in reply to:  8 Changed 13 days ago by stoecker

Replying to ris:

You two solutions both look viable, but I've got to note that they are slightly like building a homebrew CA :) It would probably be important too to capture the list of plugins a certificate holder is authorized to make new releases for.

Actually that was part of the plan. Like

  • plugin1.jar
    • pub-key1
    • pub-key2
    • ...
  • ...

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to ris
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.