FreeBSD.org intrusion announced November 17th 2012

Security Incident on FreeBSD Infrastructure
From: FreeBSD Security Officer <security-officer@FreeBSD.org>
To: FreeBSD Security <FreeBSD-security@FreeBSD.org>
Bcc: freebsd-announce@freebsd.org, freebsd-security-notifications@FreeBSD.org
Reply-To: secteam@FreeBSD.org
Subject: Security Incident on FreeBSD Infrastructure

On Sunday 11th of November, an intrusion was detected on two machines within the FreeBSD.org cluster. The affected machines were taken offline for analysis. Additionally, a large portion of the remaining infrastructure machines were also taken offline as a precaution.

We have found no evidence of any modifications that would put any end user at risk. However, we do urge all users to read the report available at http://www.freebsd.org/news/2012-compromise.html and decide on any required actions themselves. We will continue to update that page as further information becomes known. We do not currently believe users have been affected given current forensic analysis, but we will provide updated information if this changes.

As a result of this event, a number of operational security changes are being made at the FreeBSD Project, in order to further improve our resilience to potential attacks. We plan, therefore, to more rapidly deprecate a number of legacy services, such as cvsup distribution of FreeBSD source, in favour of our more robust Subversion, freebsd-update, and portsnap models.

More information is available at http://www.freebsd.org/news/2012-compromise.html

Saturday November 17th, 2012

http://www.freebsd.org/news/2012-compromise.html
 
Interesting. I didn't get how the attacker gained the access from the announcement. Did somebody "steal" that developer guy's SSH keys?

I'm used to cvsup everything for so long .. mhm ..I think it's time for me to read the handbook again.
 
The secret SSH keys of the developer (the ones on his client machine) leaked somehow and I guess they were not passphrase protected which in turn gives the attacker carte blanche what to do with the keys.
 
Wild guess: The keys were on a windows machine that got infected with a malware that was specifically made to snoop for Putty/SSH keys.
 
Maybe it is time for the FreeBSD Foundation to consider funding a two form factor authentication system when it comes to gaining access to sensitive systems.
 
PKGNG won't be imported into the base system, it will still become the official packaging system for FreeBSD eventually. CVS may be deleted from the base system because it exists as a port and it's not needed by any of the core utilities, not even csup.
 
kpa said:
CVS may be deleted from the base system because it exists as a port and it's not needed by any of the core utilities, not even csup.
There is no CVS in the base, except csup(1).
 
But there is ;)

Code:
fileserver ~ % which cvs
/usr/bin/cvs
fileserver ~ % uname -a
FreeBSD fileserver.houseofevil 9.1-RC2 FreeBSD 9.1-RC2 #0 r241541: Sun Oct 14 18:39:04 EEST 2012     root@fileserver.houseofevil:/usr/obj/usr/src/sys/GENERIC  amd64
fileserver ~ %

From src.conf(5)

Code:
    WITHOUT_CVS
             Set to not build CVS.

Are you thinking of something else?
 
That's odd, how long has it been there? Cvsweb is still down so it's nearly impossible to track back.

But yes, we can get rid of that one. As long as csup(1) is still around (and working). At least for the time being.
 
I just wanted to be 100% clear on what this affects. In the original announcement, it says that the integrity could not be ensured for "ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors."

Where does portsnap sit in the tree? Would the integrity of ports compiled from portsnap between the 19th of sep and 11th of nov be questionable in the same way as something from cvs?
 
Someone on the FreeBSD mailing list pointed this out, which pretty much answers my question:
"We have also verified that the most recently-available portsnap(8) snapshot matches the ports Subversion repository"

So, I think we'll have to assume that portsnap snapshots other than the most recent one could not be verified.
 
chatwizrd said:
I am assuming they will change this eventually maybe since everything is moving over to svn.

I am assuming that svn will never be part of the base unless a major rewrite is done to eliminate dependencies like sqlite3.
 
Uniballer said:
I am assuming that svn will never be part of the base unless a major rewrite is done to eliminate dependencies like sqlite3.

What's wrong with sqlite as dependency?
pkgng use it. And it will be part of base.


sqlite license is public domain, so no problem here.


neon however is GPL3
 
graudeejs said:
What's wrong with sqlite as dependency?
pkgng use it. And it will be part of base.


sqlite license is public domain, so no problem here.


neon however is GPL3

PKGNG will stay in ports only, this has been stated numerous times by its developers. There will be a bootstrap program in the base that downloads and installs the latest ports-mgmt/pkg. The bootstrap actually exists in 9.1-RC as /usr/sbin/pkg, it's just a wrapper that does the bootstrap on first use and passes the control to /usr/local/sbin/pkg on subsequent uses. There's been suggestions to rename to bootstrap to /usr/sbin/pkg-bootstrap to avoid confusion between two binaries with the same name.
 
graudeejs said:
What's wrong with sqlite as dependency?

You might have noticed that FreeBSD base doesn't include a web browser, GUI, or relational database manager. That's because they feel like "application" stuff, not "operating system" stuff, to operating system jocks.

Of course, I could be wrong...
 
sqlite is a single C source file. This can hardly be a problem. FreeBSD already includes a number of 3rd party applications & libraries.

There are other dependencies for svn which are significantly larger, like apr or bdb for example.
 
FreeBSD developers are opposed to adding more shared libraries to the base than is absolutely necessary, that means sqlite would have to be compiled statically into programs using it much like PKGNG does.
 
Was pkgng supposed to replace the pkg_* system? or just supplement it like port(upgrade|master) are for the ports system?

Though I could see that for embedded systems it would be nice to have something like pkgng only as then one wouldn't need a separated system for administration and building. But that's what nanobsd is for.

Finally as for application development as time goes on seamless options could be created for the so called model/view/controller style development. In the case for needing a database for model being compatible with a filesystem style database like /var/db/pkg would be simple enough for pretty much anything. Non flatfile simulated rdbms unlike sqlite could be used as well for large buildsystems where concurrency may be an issues (i.e. postgresql, mysql, nosql?) ... since the command is the controller unless c hooks are exposed it's open source so anyone could build it into another application if desired... Finally for the view what is most important is the console which we already have. This could easily be brought into a 4th generation web front-end for giving access to clients who pay for such things. The gui would have been another suggestion but we aren't on ubuntu and for the current market of automation outside of browser won't be on which gfx framework anymore.

tl;dr
Unless sqlite can provide something over structuring like /var/db/pkg does or a variation of the theme pkgng should be modular and the dependency should be optional to the user to decide.
(Disclaimer: I haven't used pkgng yet... If I'm completely overstepping my boundaries here by assuming how the pkgng package manager works please educate an inform me)
 
Back
Top