Could what has just happened to the AUR happen to FreeBSD ports?

bakul said:
I am tired of this sort of “concern trolling”. Why not talk about linux related problems in linux related forums and spare us of such discussions.
Click to expand...
because I'm a FreeBSD user and am genuinely concerned. I don't run it in production I'm not that brave, but I still don't want malware to wreck my home lab. No trolling involved. Negative attitudes today seem to abound. I would ask for the post to be deleted because of the attitudes people are giving but I won't because I think the genuine answers given by some are important and are worth keeping for others.
 
bakul it is not concern trolling to talk about FreeBSD and supply side attacks. The details why Arch Linux case is/isn't relevant for us is currently under discussion.

diizzy Ports have a checksum. The remote artifact can't change. If it changes, if it goes missing, it's a port build error.
We're talking about unmainteaned ports. We have Xyz 1.2 stale port, artifact still up there somewhere, building fine, but the Xyz is already at 1.8 and 2.x something

What happened in AUR case is somebody took those over. Cracauer explained how you can't drop in like into AUR and take ownership of them.
 
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.

Edit. P.S. Arch User Repo is hosted by Arch Linux but managed by "the community".
Lately there has been a developer around promoting his ports/packages thing. When I commented that nobody sane should use a 3rd party ports/packages system of some guy, I got backlash on the level that FreeBSD should really allow this modus for the project, that people should be able to plug in their alternatives, that it is the spirit of BSD and the rest of the bullshit. Well, there is your answer.
 
Zare said:
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.
Click to expand...
Plus that *BSD usually don't draw that much attention...
 
Tomolok said:
Plus that *BSD usually don't draw that much attention...
Click to expand...

Well yes, the AUR attack targeted developer credentials...now the fabled story that even FreeBSD core devs use Mac OSX for the desktop plays to our hand :D

BSDs are primarily used as servers or as building blocks for specialized OSes.
 
Zare said:
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.

Edit. P.S. Arch User Repo is hosted by Arch Linux but managed by "the community".
Lately there has been a developer around promoting his ports/packages thing. When I commented that nobody sane should use a 3rd party ports/packages system of some guy, I got backlash on the level that FreeBSD should really allow this modus for the project, that people should be able to plug in their alternatives, that it is the spirit of BSD and the rest of the bullshit. Well, there is your answer.
Click to expand...
I think you got it a bit wrong.
Yes, we do have checksums and so do pretty much any other repo including AUR.

.SRCINFO - aur.git - AUR Package Repositories

aur.archlinux.org aur.archlinux.org

distinfo « mtf « archivers - ports - FreeBSD ports tree

cgit.freebsd.org cgit.freebsd.org

We do allow "random people" (aka contributors) to touch these, some committers are more lax than others when it comes to changes etc for the better or worse depending on your look at it.
 
Zare said:
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.

Edit. P.S. Arch User Repo is hosted by Arch Linux but managed by "the community".
Lately there has been a developer around promoting his ports/packages thing. When I commented that nobody sane should use a 3rd party ports/packages system of some guy, I got backlash on the level that FreeBSD should really allow this modus for the project, that people should be able to plug in their alternatives, that it is the spirit of BSD and the rest of the bullshit. Well, there is your answer.
Click to expand...
I don't think there's anything that prevents something like FUR (FreeBSD User Repository) in addition to the existing portals, it's just a matter of having said repos and relevant signatures.

Also, I don't think FreeBSD or any OS, closed or open source, is imune to these kinds of attacks. The point of failure is always the same, be it what happened to Arch, XZ, etc. Someone with more or less effort just needs to gain the trust of the necessary people, lay low for a while and then it's a supply chain attack.

And, for the random internet person argument, aren't we all random people on the internet?
Is there any background check process to provide people with commiter access, and this by real legitimate entities?
 
fahrenheit said:
And, for the random internet person argument, aren't we all random people on the internet?
Is there any background check process to provide people with commiter access, and this by real legitimate entities?
Click to expand...

These are all completely different cases. The AUR problem is that it allows commits by non-committers, in effect. The XZ case was a carefully built up internet persona.

There is no formal background check.
 
cracauer@ said:
These are all completely different cases. The AUR problem is that it allows commits by non-committers, in effect. The XZ case was a carefully built up internet persona.

There is no formal background check.
Click to expand...
That's trust-based and not really waterproof. A known committer with positive history can go there as well. While I only produce offline software, it would be interestinng to see an official checklist for administrators to avoid supply chain trouble.
The FreeBSD system is reliable thanks to a large amount of academic organisations that host the sources, so any fie difference will always be noticed soon. But how about the ports? What happens if a bad commiter plugs a rootkit in some obfuscated code that's auto-installed by make and makes it look like a nice visual update? Many users could build and install a malware as privileged user while unaware.
 
MG said:
That's trust-based and not really waterproof. A known committer with positive history can go there as well. While I only produce offline software, it would be interestinng to see an official checklist for administrators to avoid supply chain trouble.
The FreeBSD system is reliable thanks to a large amount of academic organisations that host the sources, so any fie difference will always be noticed soon. But how about the ports? What happens if a bad commiter plugs a rootkit in some obfuscated code that's auto-installed by make and makes it look like a nice visual update? Many users could build and install a malware as privileged user while unaware.
Click to expand...

A bad committer that obfuscates well will lead to a compromise.

Same for any organization. Google does background checks, but what really is the value? They aren't magic.
 
ioverreact said:
because I'm a FreeBSD user and am genuinely concerned. I don't run it in production I'm not that brave, but I still don't want malware to wreck my home lab. No trolling involved. Negative attitudes today seem to abound. I would ask for the post to be deleted because of the attitudes people are giving but I won't because I think the genuine answers given by some are important and are worth keeping for others.
Click to expand...
I think it's a valid concern, there are certainly policies/guidelines for cases that should be defined.
There's also no official policy for forks (non endorsed by upstream / recognised ones that is), although multiple committers have raised concerns about adding such to the tree there still are some who will add these.

In general I say that there's a much higher risk when you're running outdated software, abandonware and your box is connected online than installing rouge malware/software from an official package regardless of major distro.

As for FreeBSDs ports tree while most "core" software projects are up to date there are some lagging behind, a major one for example is Python and friends.
 
As a FreeBSD user, running binary packages (freebsd-update and pkg upgrade on quarterly), if an update to a package is not accepted into quarterly there is (I think) minimal risk. Zero risk? No, but updates to ports need to be accepted, which is where the risk comes in.
 
ioverreact said:
I updated the title at 1.25pm UK time, which was hours before bakul made comment 😑
Click to expand...
Well I'm glad you posted it, it raised my awareness of another class of attack, and its good to know about these things. Hopefully freebsd is not quite so vulnerable to this, as other posters have mentioned, although clearly there are always going to be risks.
 
mer said:
As a FreeBSD user, running binary packages (freebsd-update and pkg upgrade on quarterly), if an update to a package is not accepted into quarterly there is (I think) minimal risk. Zero risk? No, but updates to ports need to be accepted, which is where the risk comes in.
Click to expand...
It's more likely that updates don't make it into quarterly due to lack of time (mainly testing). Quarterly branches can diverge quite a bit from head/master branch so you may need to do all testing again which takes quite a bit of time and effort unless you bypass testing/qa which may cause breakage. Ideally it would be nice if you could hand it off to someone else / have some offloading but unfortunately that isn't possible in most scenarios.
 
mer said:
As a FreeBSD user, running binary packages (freebsd-update and pkg upgrade on quarterly), if an update to a package is not accepted into quarterly there is (I think) minimal risk. Zero risk? No, but updates to ports need to be accepted, which is where the risk comes in.
Click to expand...
waitaminute, package repos are built from the Ports Collection. Github has a read-only mirror.

From the way the whole thing is built, I'd think that Ports Collection (not package repos like quarterly/latest/arch-dependent/etc) would be the place that accepts commits. Package repos just take whatever compiled successfully, anyway.

But I'd think that trimming some fat from the Ports Collection (like Perl/Python/php/etc modules) would be a good way to make the maintenance and security of the Ports Collection a bit easier. Maybe draw some inspiration/ideas from OpenBSD ? ;)
 
cracauer@ said:
In case you didn't spot it, the AUR mess goes into another round. That is after 1500 malicious packages were discovered.

Arch Linux AUR Hit By Another Wave Of Now More Sophisticated Malware Attack - Phoronix

www.phoronix.com www.phoronix.com
Click to expand...
1781504414575.png
 
You must log in or register to reply here.
Back
Top