#4043 Plugin Manager using HTTP for Updates/Install

normal bug
security (1)

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.

4 Attachments


  • Alan Ezust

    Alan Ezust - 2017-08-10

    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.

  • 0x10F8

    0x10F8 - 2017-08-10

    I tried to create some java code that downloaded files through redirects over TLS. There appears to be a problem with sourceforge TLS configuration.


    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.

  • 0x10F8

    0x10F8 - 2017-08-11

    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).

    Last edit: 0x10F8 2017-08-11
  • 0x10F8

    0x10F8 - 2017-08-14

    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.

  • Alan Ezust

    Alan Ezust - 2017-08-15

    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.

  • Alan Ezust

    Alan Ezust - 2017-08-15
    • assigned_to: Björn Kautler

Log in to post a comment.