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.
Agreed. For a while there, I had a GitHub account for years and only made one commit to an open source project, and basically did nothing else. I use another hosted Git platform for my day to day work, as well as self hosted repositories.
In fact, even to this day, the amount of activity on my Github account (commits to other repos) can be counted on one hand.
Does it matter? Motives are often inscrutable. The code was merged regardless. The point of the article to my reading was to ask for better standards, not necessarily to sensationalize.
The blog post seems much more like it's written to say "this was probably innocent but we need to address the possibility that it's not in order to protect projects from malicious actors".
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.
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.
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?
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.
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.
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.
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.
19 comments
[ 3.4 ms ] story [ 62.9 ms ] threadIn 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.
Interestingly though, there exists a pinterest account with the same email address "lecoeurlou@gmail.com" for a Louise Lecoeur
In fact, even to this day, the amount of activity on my Github account (commits to other repos) can be counted on one hand.
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.
Do you auto-watch the authors of your code, for false profiles? Meaning if they are obviously abandoned, you revert there commit?
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.
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.
https://www.youtube.com/watch?v=U4e0Remq1WQ (jump to minute 33)
Great talk, appreciate the link.
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.
https://vigilance.fr/vulnerabilite/Joomla-Core-trois-vulnera...
http://www.cvedetails.com/vendor/3496/Joomla.html
http://www.cvedetails.com/vendor/3496/Mambo.html
https://www.cvedetails.com/product/3827/Mambo-Mambo.html?ven...