WordPress.org

Making WordPress.org

Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#4662 closed enhancement (duplicate)

A security risk on W.org plugins repository - no checksum / authorization of plugin version reporting

Reported by: KestutisIT Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

As it came up on 5th comment in ticket #4661 ( https://meta.trac.wordpress.org/ticket/4661#comment:5 ), it appears that there is absolutely not authorization on what is getting reported to plugin's advanced view -> versions. As @Ipstenu confirmed, for plugins there is not even SemVer validation used (as of SemVer.org), so it means that EVIL PERSON, can create an /akismet/ plugin, that has over 5 millions of current installs, and create a version in that plugin named Automattic has nothing to do with WordPress and that message will be seen to everyone who will visit https://wordpress.org/plugins/akismet/advanced/ page.

So, as I have partnered with PayPal many times and did many PayPal integrations, I can confirm that the most secure way for this, is to generate SHA2-512 or RSA *.cer file for each plugin after it is released and keep that file in plugins folder. The certificate (*.cer) will ensure that request is coming from that exact plugin from that exact author.

In a perfect world, the checksum would be from a whole plugin's zip file, as PHPUnit is doing.
But for minor case the checksum should be at least calculated from w.org plugin URL and either:

  1. Plugin's admin dashboard left menu image icon checksum
  2. Or whole Plugin/Plugin.php (main file with meta description)
  3. Or just a meta description.
  4. Or plugins readme.txt file (as @Ipsteinu told that this is the only always required file).

Maybe at the same time it will mean, that we should add a support for versions.md (as GitHub loves .md and we are in new era of .md). So that we don't need to update a certificate file so often as otherwise checksum will change often, while if versions part would always be away of the readme.txt, then it will not need to update that often.

Note: And even if SemVer (Semver.org) validation would be done there, we still can create a bot that would report a million of installations of Akismet of '99.99-EVIL-TEXT', and Semver allows to name the release.

So that's a security risk.

Change History (5)

#1 @KestutisIT
4 months ago

  • Summary changed from A security risk on W.org plugins respository - no checksum / authorization of plugin version reporting to A security risk on W.org plugins repository - no checksum / authorization of plugin version reporting

#2 @Otto42
4 months ago

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #619.

This has already been discussed many times, and is currently a work in progress.

See:

#3 @Otto42
4 months ago

https://meta.trac.wordpress.org/ticket/619
https://core.trac.wordpress.org/ticket/20074

And probably other core tickets as well. Nevertheless, this would need to be a core implementation, it's not something we can wholly do on the w.org side.

#4 @Otto42
4 months ago

  • Keywords needs-patch removed
  • Priority changed from high to normal
  • Type changed from defect to enhancement
Note: See TracTickets for help on using tickets.