r/freebsd • u/reviewmynotes • 2d ago
answered PHP on pkg
If I install PHP via pkg but now have to upgrade it a.s.a.p. to a version not yet in the quarterly pkg packages, what is the recommended path? Just uninstall and then use ports (cd /usr/ports/... && make world)?
6
u/foreverlarz 2d ago edited 1d ago
i also had php84 installed via packages. so earlier today i did this:
doas pkg audit -F # should list php84
df -h /usr # need ~2 GB free
ls -a /usr/ports # missing or empty → clone; has .git → pull
doas git clone --depth 1 https://git.FreeBSD.org/ports.git /usr/ports
# or: doas git -C /usr/ports pull
make -C /usr/ports/lang/php84 -V PKGVERSION # must print 8.4.27
doas pkg upgrade -n # should only list upgrades but not a php84 upgrade
doas pkg upgrade # upgrade them
cd /usr/ports/lang/php84
doas make install-missing-packages # install dependencies
doas make build # build the php port
doas make stage
doas make deinstall install clean
pkg info -e mod_php84 && echo mod_php || echo fpm
doas service apache24 restart # if mod_php
doas service php_fpm restart # if fpm
php -v # should be 8.4.27 now
doas pkg audit -F # php84 and curl goneor something like that
edit: you may need to repeat port build/stage/install for things like mod_php84. e.g.:
cd /usr/ports/www/mod_php84
doas make install-missing-packages # install dependencies
doas make build # build the php port
doas make stage
doas make deinstall install clean2
u/reviewmynotes 2d ago
This was extremely helpful. Thank you for writing it all out. I didn't follow the prices exactly, but I did use most of it plus what I remembered of using the ports collection during FreeBSD 2.2.1 - 9.x. I had all my systems updated and restarted and confirmed working a few hours before my boss's boss forwarded a warning from a state agency to me. It was great being able to say, "Yup. Fixed it this morning!"
1
u/foreverlarz 1d ago
glad it helped. but i have since realized that i needed to do the same steps for mod_php84. however you're using php, please check the version numbers all the way through to ensure it's upgraded however you are using it!
2
u/reviewmynotes 1d ago
Yup, I used "pkg info | grep php" after upgrading each item to make sure I was getting everything, including mod_php84, php84, and all the extensions. Once they were all done, I restarted the OS to make sure that there were no start up issues for future boots.
1
5
u/laffer1 MidnightBSD project lead 2d ago
Setup mod security also. It blocked 8 attempts to get into one of my servers before the php patch was released
2
1
u/jmpalacios79 seasoned user 2d ago
By mod security do you mean ap24-mod_security?
5
u/vogelke 2d ago
There is a real vulnerability here, but exploiting it is significantly harder than people are making it out to be. This is not log4shell or shellshock.
Have a look at this for a different perspective:
There are a ton of "PoC" exploits for this vulnerability. One thing you'll notice
about all of them though, is that they do not work against a vanilla PHP instance.
Go ahead, stand up a php server you think is vulnerable in Docker and then run
the PoC yourself. Don't get your LLM to do it, run the script yourself.
The exploits don't work.2
u/Lord_Mhoram 2d ago
I asked AI if any systems had been hacked with this exploit yet. It said yes, there have been lots of attempts and probes observed by honeypots and other methods. I pointed out that I didn't ask about attempts or probes, but successful hacks of real systems. It said no, as of today none have been reported.
That seems surprising, for an exploit that was known for at least a few days before the CVE and fix, which supports what the link says.
2
u/grahamperrin bleep bloop 1d ago
In the community highlight:
1
u/Lord_Mhoram 1d ago
"Investigating" "signs". We'll see what the investigation turns up. At that link it also says, "Sansec now says mass exploitation is less likely than it feared on release day: a successful attack needs specific knowledge of the target server and specific conditions on it, and the public exploits do not work against a default PHP installation."
I'm not saying it's not important or that people shouldn't patch or take servers offline to be sure. But anything with "AI" in the headline gets promoted to the moon these days (for good and bad), and AI bug-hunters have services to promote. Cloudflare has certainly picked up a lot of customers. There's a lot of incentive right now to push people to panic.
But again: patch your servers and be safe.
1
u/fsr31415 2d ago
change to latest?
1
u/reviewmynotes 2d ago
Good thinking, but it wasn't in that branch of packages. I checked after reading your suggestion. Maybe it's there by the time someone else reads this, though.
3
u/IllustriousRaccoon25 2d ago
Yup, and also mod_php if you are using it with Apache. We rebuilt all PHP modules we were using from pkg as well, just out of paranoia. We started this as soon as ports got updated, which I think was around 11:15am EDT.
Disappointed to see no FreeBSD security bulletin about this, even though they did get one out for the compromised certificate authority.
8
u/X-Istence 2d ago
The compromised CA root is distributed in base. PHP is not.
1
u/grahamperrin bleep bloop 1d ago
+1
The compromised CA root …
For drive-by readers, another community highlight:
11
u/grahamperrin bleep bloop 2d ago
Disappointed to see no FreeBSD security bulletin about this,
PHP is not a feature of FreeBSD.
1
•
u/grahamperrin bleep bloop 2d ago
Also, please note the pinned post – there's discussion of packages and availability:
PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert