Previous Next Tracker index See it online !

(195/211) 4043 - Plugin Manager using HTTP for Updates/Install

As the plugin manager uses HTTP man in the middle of plugin manager communication is trivial.

If the (plugin-manager.export-url) /export/gzip_plugin_manager.php call is intercepted and respose modified then plugin installation and updates can be compromised and remote code execution can occur (through providing malicious plugin jars in URLs in the response XML). Or even if the gzip_plugin_manager.php call isn't intercepted then future calls can be intercepted and a redirect to malicious jars can be provided.

Suggest that TLS is used where possible and code signing of plugins (and display warnings or blocking unsigned plugins).

Implications are that using jedit on a public network (coffee shop, airport etc) could allow remote code execution.

Submitted	x10f8 - 2017-08-09 23:31:47.755000	Assigned	vampire0
Priority	5	Labels	security
Status	open	Group	normal bug
Resolution	None

Comments

2017-08-10 00:50:48.863000 ezust	I know it was changed to http in order to allow for redirect messages to come from the sf.net server - it seems before, the redirects failed, and users were unable to download any plugins at all.
2017-08-10 21:58:57.288000 x10f8	I tried to create some java code that downloaded files through redirects over TLS. There appears to be a problem with sourceforge TLS configuration. https://hastebin.com/vifabelupu.java If you use the above code with the "test2" URL it not only works but follows redirects as normal. The sourceforge download URL fails at initial handshake (Tested Java 1.7.0_80 & 1.8.0_144). Working test URL handshake: https://hastebin.com/uxevecetap.txt Sourceforge handshake: https://hastebin.com/gacazanumu.txt It looks like the sourceforge handshake is trying to respond with a TLSv1.2 alert even to TLSv1.1 requests which also seems suspicious (possible server configuration issue). I think if the handshake issues with the sourceforge server can be resolved then you would be able to download updates with TLS. I'll continue to investigate to see if (I'm missing something/there's a workaround) for the sf.net issues.
2017-08-11 09:20:19.869000 x10f8	Solved issue by installing unlimited strength JCE jars (http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html). I believe the issue is that the java client isn't sending any compatible ciphers to the server (and thus the server rejects the handshake).
2017-08-14 21:27:14.677000 x10f8	I made a ticket with sourceforge who indicate they may change the server config (https://sourceforge.net/p/forge/feature-requests/585/). Which would allow TLS downloads to happen.
2017-08-15 07:10:38.942000 ezust	Thanks for your help. I will also review and apply any patches you might have to jEdit to fix this up. This is not code I've worked on personally before though, so I will also add Vampire to the ticket.
2017-08-15 07:10:53.258000 ezust	- assigned_to: Björn Kautler