
Was Joomla Sabotaged? - markdown
http://www.fionacoulter.com/blog/was-joomla-deliberately-sabotaged/
======
WordSkill
Anyone asking how a malicious submitter might have guessed that his patch
would receive no oversight should take a look at the official directory for
Joomla extensions, JED, where it has now become next to impossible to work out
which extensions are actually good thanks to being overrun with fake reviews
and ratings.

These directories are useless if the system can be so easily gamed. The scammy
owners of low-quality extensions learned, long ago, that no-one is applying
even the most basic checks to reviews, so, anything goes. Fake reviews defraud
users and are a serious disincentive to honorable plugin developers, trying to
gain momentum through hard work and genuine support. This hurts Joomla.

I know the full-time developer of an extremely good, complex, long-standing
Joomla extension who has tried, in vain, to get the Joomla leadership to
address this issue, because it is clear that certain extensions are dominating
their category with a stream of obviously fake reviews, but they won't even
acknowledge the problem.

A similar complaint to the WordPress.org plugin got the fake reviews removed
in less that 24 hours. I don't want to get into tribal warfare over the
relative merits of these projects - I want all Open Source projects to thrive
- but it is worth noting that much of the success that WordPress has enjoyed
over the past decade is down to being able to motivate participants to pay
attention to the small, unglamorous details such as the integrity of their
directory reviews, such things reflect the care and attention being applied to
a project as a whole.

------
droithomme
That fix is small, fixed an actual bug, and the security vulnerability it
revealed as a side effect wasn't obvious at all.

It's hard to imagine what level of security review on patches would result in
catching this without bringing development to a halt. Also any such level of
security review necessary that could find such problems could also 'simply' be
done without waiting for any patches. Presumably the reason it is not is
because it is not really so simple.

~~~
na85
It's much better from a self-esteem perspective to assume your project was a
victim of its own incredible success than it is to have to confront the idea
that your project was/is just plain written poorly.

That way you can blame github for a lack of patch review instead of being
forced to reconcile with the fact that parts of your project suck.

------
__david__
Meh. This is way too conspiracy theory-ish. Some people don't live their lives
on Github, but I think some of the people that do can't fathom that anyone
else wouldn't (similar to certain twitter/facebook users).

In the past I've done drive by patches to projects by signing up for a mailing
list, dropping off my patch and unsubscribing a week later. Some of those
patches might have even had bugs in them (it happens to the best of us)—they
certainly weren't intentional.

This is reading way too much into an abandoned account—there are _way_ more
totally legit reasons to abandon an account than there are nefarious ones.

~~~
ryanlol
Well, FWIW the gmail account attached to the github really looks like its been
registered specifically for this.

Interestingly though, there exists a pinterest account with the same email
address "lecoeurlou@gmail.com" for a Louise Lecoeur

------
hannob
Something very similar happened to Angular.js (however it wasn't malicious, it
was done by whitehat security researchers to prove a point):

[https://www.youtube.com/watch?v=U4e0Remq1WQ](https://www.youtube.com/watch?v=U4e0Remq1WQ)
(jump to minute 33)

~~~
dude01
Great talk (it's about pen testing Angular 1 apps, not Angular 2).

I have mixed feelings about the "whitehat" security person intentionally
submitting a flawed bug fix (into the _real_ Angular code base) so that they
could introduce a security vulnerability in an open source project. At least
they made sure their vulnerability didn't appear in an actual release, and
they had given a warning to the Google security team, but not the Angular
team, about what they intended.

Perhaps the only thing I really learned is that if a "whitehat" security
person thinks it's a legit concern to make a malicious patch to an open source
project, you can be darn sure there are lots of blackhats doing the same thing
on other projects right now.

------
matteuan
Probably the guy knew about the vulnerability before, and this should not
surprise anyone, but saying that Joomla was 'Deliberately Sabotaged' has a
completely different meaning. I don't see the connection or where the autor is
pointing at.

------
based2
[https://developer.joomla.org/security-
centre.html](https://developer.joomla.org/security-centre.html)

[https://vigilance.fr/vulnerabilite/Joomla-Core-trois-
vulnera...](https://vigilance.fr/vulnerabilite/Joomla-Core-trois-
vulnerabilites-20947)

[http://www.cvedetails.com/vendor/3496/Joomla.html](http://www.cvedetails.com/vendor/3496/Joomla.html)

[http://www.cvedetails.com/vendor/3496/Mambo.html](http://www.cvedetails.com/vendor/3496/Mambo.html)

[https://www.cvedetails.com/product/3827/Mambo-
Mambo.html?ven...](https://www.cvedetails.com/product/3827/Mambo-
Mambo.html?vendor_id=842)

------
Pica_soO
And how to prevent that? Does a account need a history of accepted pull-
request? Do you declare Security Sensitive Project Codezones, where only
established maintainers can commit?

Do you auto-watch the authors of your code, for false profiles? Meaning if
they are obviously abandoned, you revert there commit?

------
zzzcpan
Whether it was malice or not, you should always think about how something like
this could have been prevented instead of blaming people. And I believe even
the simplest framework with proper isolation and explicit crossing of trust
boundaries could eliminate these kinds of security problems.

------
arnorhs
[https://en.wikipedia.org/wiki/Hanlon%27s_razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor)

