Contributed by jose on from the verifiable-advisories dept.
FreeBSD and Debian, to name two examples, send out their advisories signed via PGP (GnuPG) making it easy to verify the message is really coming from the Security Officer.
It shouldn't be hard to send out a fake advisory pointing to a malicious patch somewhere on an FTP. True, while real OpenBSD users always check the errata page before installing patches, this doesn't seem to be in line with the proactive approach that makes OpenBSD OpenBSD. Also true, people falling for this trick may probably not be the persons who could be saved from this by using GnuPG (probably they don't use it anyway) but I mean... just as a precaution. We OpenBSD folks like security. And thus we should like verifying such important things as advisories for authenticity and integrity.
Furthermore, wouldn't it be wise to add MD5 checksums to the patches on the FTP server and mention these in the advisory?
It's not totally clear to me why OpenBSD doesn't do this."
(Comments are closed)
By gwyllion () on
Comments
By Anonymous Coward () on
Regards
Comments
By gwyllion () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
in ports. And there's the rule in OpenBSD that
no more GPL'd (or more-restrictive-than-BSD at
least) code be added any more (gcc 3.x was the
exception to the rule I think).
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
pgp 2.6.3in are alternatives, totally free for
private individuals, and for anyone outside of
countries with the IDEA patent).
But what's so difficult about using S/MIME?
I've even written a (signing) plugin for pine.
https://mirbsd.bsdadvocacy.org:8890/active/cvsweb.cgi/ports/mail/pine/files/pine.smime.init
is called instead of pine, and you fool pine into thinking that
https://mirbsd.bsdadvocacy.org:8890/active/cvsweb.cgi/ports/mail/pine/files/pine.smime
is sendmail.
Verifying is just as easy (openssl smime -verify)
once you have /etc/ssl/certs/ set up.
Comments
By Han () on
You can safely ignore anything he says about anything that involves GPL'ed code. He went berserk over somebody mentioning --longopts.
Ask why he doesn't like it :)
By Anonymous Coward () on
Comments
By Anonymous Coward () on
I can't think of any reasons why signed advisories are a good idea. Care to share some ideas why they are relevant?
Comments
By dantams () on
Comments
By pravus () on
and re-read my earlier post about MD5 hashes. nowhere in your statement did you mention signing the MD5 sums.
Comments
By Anonymous Coward () on
Removing a machine from a network will stop it being compromised by any but a burgler.
Comments
By pravus () on
By dantams () on
As if there was a solution that was 100% secure. At least it is a lot more secure than now.
If the advisory is signed and the advisory includes the MD5 sums, are the MD5 sums not signed??
By Martin Schröder () martin@oneiros.de on http://www.oneiros.de
Comments
By mirabile () mirabile@bsdcow.net on http://mirbsd.de/
the last two years or so, even opened a PR.
It was closed with "this won't happen, sorry."
MirBSD ships with a skeleton known_hosts file
which contains what I know about most of the
OpenBSD ssh keys - but without knowing if the
values are actually correct, that's only for
these of my infrastructure.
By Anonymous Coward () on
If it is of serious interest I will consider writing one. (NO key management, no encryption, no symmetric encryption, just verify, minimal cipher suite)
Comments
By djm () on
By lcteo () on
There's no point re-creating a BSD-equivalent of a heavyweight app like GnuPG again just to do simple tasks.
By Anonymous Coward () on
The fact the change now lives in the CVS repository is all the signature you need.
> "FreeBSD and Debian, to name two examples, send out their advisories signed via PGP (GnuPG) making it easy to verify the message is really coming from the Security Officer."
Verifying him is irrelevant. He/She is not the problem nor the solution to the problem.
> "It shouldn't be hard to send out a fake advisory pointing to a malicious patch somewhere on an FTP."
No, it is not hard.
> "True, while real OpenBSD users always check the errata page before installing patches, this doesn't seem to be in line with the proactive approach that makes OpenBSD OpenBSD."
Signing a waste-of-time is being proactive? If so, OpenBSD has definately violated its goals.
>"Also true, people falling for this trick may probably not be the persons who could be saved from this by using GnuPG (probably they don't use it anyway) but I mean... just as a precaution."
"Just a precaution" to those who know better? Pointless. Irrelevant. A waste of time.
> "We OpenBSD folks like security. And thus we should like verifying such important things as advisories for authenticity and integrity."
Integrity of the patch is important, not a message that mentions a patch exists.
> "Furthermore, wouldn't it be wise to add MD5 checksums to the patches on the FTP server and mention these in the advisory?"
A fake advisory and a real advisory look the same. I don't see the reason why it should be done.
Comments
By pravus () on
also, i'd like to point out that MD5 sums for anything on a server gets you *nothing* security-wise. if someone is able to crack a machine, what's to stop them from changing all of the MD5 sums to match the infected material? you'd download it, verify it, and happily install trojaned material on your machines. MD5 sums mean nothing. learn it, believe it, move on.
let's face it. there is no magic bullet when it comes to security. everyone who thinks that using this program or that language is simply lieing to themself. security is a process that must continually evolve with the ever-changing environment of computing.
Comments
By dantams () on
Comments
By pravus () on
Comments
By krh () on
It won't stop anyone with brains, of course, but it's a little better than nothing.
Comments
By Anonymous Coward () on
MD5's are usefull for verifying that you've downloaded a file correctly, and nothing more.
You can't rely on the stupidity of attackers.
Comments
By Anonymous Coward () on
By Charles Hill () on
Not necessarily true. If the message itself contains the MD5 sums, then the sums are signed and you can check against THOSE.
This way, when you download a patch you can compare agains MD5 sums that haven't been tampered with.
By signing the advisory, you are placing trust in a controlled location -- the security person. You're trusting that they take reasonable care with their private key.
Thus, a signed advisory with MD5 sums in the advisory GREATLY REDUCES the probability of faked messages, patches, etc.
Is it 100% fool proof? No, but it goes a long way in the right direction.
Comments
By dantams () on
By Chris Humphries () chris@unixfu.net on http://unixfu.net/
the advisory in the email should be in sync with the cvs repository and website about errata. if there is a difference, then only 2 things are possible.
1) if the email is different from the site or not on the site, then it is not to be trusted.
2) if they are the same, then it is to be trusted. if you still do not trust the advisory, then there are bigger problems, such as cvs.openbsd.org comprimised again.
signed emails are all about trust. do you trust the system that is in place or not. there is no halfway trust. either you trust how openbsd does things now, or you do not... and having signed advisory emails will not fix that.
Comments
By Anonymous Coward () on
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
Oh boy. Signed advisories won't solve your problem.