Backdoor discovered in ProFTPd

SirDice

Administrator
Staff member
Administrator
Moderator
I see a lot of posts about ProFTPd so I assume it's used quite a lot. It was discovered that the servers that had the ProFTPd sources where compromised and the source had been changed to include a backdoor.

The ProFTPD Project team is sorry to announce that the Project's main FTP server, as well as all of the mirror servers, have carried compromised versions of the ProFTPD 1.3.3c source code, from the November 28 2010 to December 2 2010. All users who run versions of ProFTPD which have been downloaded and compiled in this time window are strongly advised to check their systems for security compromises and install unmodified versions of ProFTPD.
Source: http://www.proftpd.org/

If you have installed the ProFTPd port during that time period it is highly recommended to uninstall it and reinstall. The port has been updated yesterday and will install the correct (non-backdoored) version.
 
You can check archive again signature, which is VERY hard to fake.
Unlike checksums, which can also be stored on server, to check signature you need to already have public key of person, who signed archive.
With source code repositories it's a little harder...
On other hand someone could write plugin/patch for repository software to also check gpg signatures... and only allow to push from trusted signatures.

You follow me?
 
Am I correct in thinking that this won't have affected anyone using ports? Ports checksums about any TAR balls it uses so this would cause the build to fail wouldn't it?
Can anyone confirm?

ta Andy.
 
Yes, it would, unless, maintainer updated port for software, that already was "patched" by criminals....
At this stage, maintainer has no chance to check if archive is legitimate
 
AndyUKG said:
Am I correct in thinking that this won't have affected anyone using ports? Ports checksums about any TAR balls it uses so this would cause the build to fail wouldn't it?
Can anyone confirm?

There was a small window of time where the port had the wrong checksum. It got updated because the port maintainer thought the source was changed. That means there's a window where the port would actually install the backdoored version.
 
killasmurf86 said:
Yes, it would, unless, maintainer updated port for software, that already was "patched" by criminals....
At this stage, maintainer has no chance to check if archive is legitimate

That is exactly what happened.
 
It might but I don't think it's that easy to implement in our ports tree. First, all of the 22000+ ports would need to use it. Second, the whole ports system would need an overhaul to check on this.

A little diligence by the port's maintainer could also have prevented it. When a checksum suddenly changes but there's no version change, nothing in the changelog and no mention of that change on the website I would have sent the developer an email asking what was going on. Instead the checksum was blindly updated.
 
killasmurf86 said:
A reason why all source code archives should be gnupg signed.

Presuming the public key is distributed safely (e.g. key server), then of course this is the correct approach.

Leaving FreeBSD Ports out of the discussion for a moment, a digitally signed source archive would have stopped this breach dead in its tracks. Where the signature check falls down is if/when package (and Ports) maintainers are not checking the sig before merging changes into their own OS sources.

Note that I'm not criticizing any maintainer, nor am I volunteering to take over management of this particular Port. Just expanding on the idea behind killasmurf's post.
 
Ye, well, it might be good idea to mention this in porters handbook...
You know, sometime you just don't think about why it changed.... especially when you never had such experience before.
 
killasmurf86 said:
A reason why all source code archives should be gnupg signed.
IMHO you are wrong.
PGP(gpg) crypto algorithm itself is strong enough, but a model of trust to a public key itself is practically around zero.
Check for example public key of <security-officer@FreeBSD.org>.
The key is untrusted since nobody confirm it that is really belong to <security-officer@FreeBSD.org>.

Check latest advisories for example
Code:
# fetch http://security.freebsd.org/advisories/FreeBSD-SA-10:10.openssl.asc]

[code]
gpg: Good signature from "FreeBSD Security Officer <security-officer@FreeBSD.org>"
gpg: WARNING: [b]This key is not certified with a trusted signature![/b]
gpg:          [b]There is no indication that the signature belongs to the owner.[/b]
Primary key fingerprint: C374 0FC5 69A6 FBB1 4AED  B131 15D6 8804 CA6C DFB2


killasmurf86 said:
Ye, I'm just saying, why things like GnuPG should be popularised
It is IMHO useless since public keys is non trusted and not verifiable. Anyone can submit a fake public key to pgp key-server that will represent another person.
The only way to confirm PGP(GPG) public keys - via unknown volunteers from web-of-trust that is also questionable because one can submit a bunch of public keys and sign own keys against each other that will create ala trusted key since at list 3 other keys confirm it.
PGP doesn't have tree form of trust model where each new member must be verified by root members before publishing new keys on a public servers.

anomie said:
Presuming the public key is distributed safely (e.g. key server), then of course this is the correct approach.
I'm not sure that is the correct approach.

Go to the http://http-keys.gnupg.net/ or any other pgp key servers and search for <security-officer@FreeBSD.org>
Do you see there fresh key 5180E90F ? The only difference between FreeBSD key and another one is a message "(test-don't trust this key)" in main field to whom key is belong.

I just "safely" submitted it. Am I a new member of "Security Officer Team" now? :)
Of course not, because that key should match also with http://www.freebsd.org/doc/handbook/pgpkeys.html (I afraid a few people know that they exist on the freebsd web site anyway.)
And what about if one hack FreeBSD's HTTP server and replace those keys shown above?
What about if one hack repository and resign with own key some codebase?
CVS doesn't support hashing of objects and integrity checking as it done by git for example, so it would be possible to change some codebase in a few important projects.
Some thought about CVS http://blogs.sans.org/appsecstreetf...series-rank-20-download-code-integrity-check/
Since FreeBSD use repositories CVS and SVN that are by its nature are centralized to compare with DCVS - all software could be broken in one place.

This topic itself show that no one can be 100% sure that servers can't be broken by hackers and public keys wouldn't be be replaced.

Did you heard also that a few days ago was hacked Savannah project that host a lot of free software which also used by FreeBSD project too?
http://packetstormsecurity.org/news/view/18237/GNU-Savannah-Hacked.html

As you can see PGP sign can't protect project(s) because of non trustful model of PGP mechanism on signing of public keys over common PGP key-servers.
It will be really great if budget of donations to FreeBSD will assume to spend a few hundred bucks out of thousands donated money per year to get signed by trusted third party certificate authority(Verisign, Equifax, StartCom...) SSL certificate.
By the way, StartCom running by a really nice guy who comes from OSS community and I think he can make a discount to such project as FreeBSD.
SSL certificate itself IMHO should be preferably at least of class 2 certificate with extended validation since simple certificates it's just verification by email and assumption that payer is an original owner of credit card that is not obvious as you know.
Extended validation is much more trustful since it's involve verification of official documents that confirm ownership of key holder.
By using S/MIME(SSL) instead of untrusted PGP(gpg) that would be practically impossible to make some changes on servers because public SSL key is signed by trusted third party certificate authority and any downloads then can be verified against CA automatically.
For now until PGP signs is in use we just hope that FreeBSD sites is not hacked in current moment when we download security advisories for example.
Using X.509 could resolve at least an issue in case of successful attack to FreeBSD sites, but couldn't resolve this problem with ports.
Actually it can be solved too if freebsd will get signed X.509 certificate itself and will host non redistributable PGP key-server that will hold only commuters and approvers public keys which would be under protection of trusted freebsd server in this case.
The model of trust to PGP keys of contributors can be implemented as a tree model,- root member sign chiefs of approval departments after personal verification, then chiefs of departments sign public keys of members of their department and so on could be created trusted tree.
All chain of PGP public keys of approvers can be signed by root member who is hold verified SSL certificate.
In this case simple script can verify tree of approver's public keys automatically and only after that verify public key of maintainers that should be signed by approver of particular port.
Only this model can be trustful, otherwise PGP signs is IMHO useless.

Somewhere I saw it - "Sure I'm paranoid, but am I paranoid _E_N_O_U_G_H_?" :)
Savannah's and ProFTP's issues show us that IMHO we need to mind folk's wisdom: "Smart people learn to the mistakes of others, ordinary people learn to their own mistakes and only fools never learn to nothing."
 
AlexJ said:
Only this model can be trustful, otherwise PGP signs is IMHO useless.

You're wrong...
USA toops pull in Verisign, and will fake certificate... no problem :)

Nothing, absolutely nothing can be trusted....
You can't even trust yourself, because over time you're brain will "Fix" memories, erase "Unneeded stuff" etc.

Heck, you can't even know if you're plugged in Matrix or not :D
 
killasmurf86 said:
You're wrong...
USA toops pull in Verisign, and will fake certificate... no problem

No, they can't until you keep in a safe place your private key.
It's impossible to fake someone's public key without having private key.
BTW, x.509 is a pretty tough market because they need to pass annual security audit, there're more than 50 certificate authorities(CA) around the globe and everyone can choose preferred one(Verisign btw is most expensive one, but hold almost 50% shares of this market)

killasmurf86 said:
Nothing, absolutely nothing can be trusted....

:)
It's more philosophical question, but in fact it is better to have trustful model than nothing at all as it works with PGP.
Certificate authority exist to verify persons(organizations) - who they are in real life and after that they will give a warranty that if somebody faked supplied to them public key or they mistakenly identify wrong person, then they will pay thousands of dollars for their mistake.
So, it's up to you which model of trust you prefer - that one, where CA can be kicked out of business if they didn't verify ownership of key's holder correctly or trust to nothing at all (PGP model), as I already explained with key 5180E90F example.

killasmurf86 said:
Heck, you can't even know if you're plugged in Matrix or not
:) You see, everybody has a paranoid syndrome :)
 
Back
Top