Dear Gentoo Security Experts,
I am very proud to announce that I have managed to perform
the crucial security fix assignment I have been given by
Kurt Lieber and Dan Margolis. After I had kissed some ass,
publicly humiliated myself, and swallowed a couple of dozen
insults, I was deemed worthy enough to do what Kurt referred
to as "to work with [him] to help [finding] ways to fix it".
For various reasons which he didn't bother to elaborate on
the public mailing list -- probably for good reason --, it
turned out that my suggested solution to the fact that
Gentoo users all over the Internet are completely
defenseless against man-in-the-middle attacks was considered
absolutely unfeasible.
So he informed me that the ONLY WAY to do anything against
that little glitch is to sign the daily Portage snapshot
that's available for download with "emerge-webrsync". This
does protect a flabbergasting total of ... I dunno ... maybe
.1 percent of the user base, so it is better than nothing.
Since all the Gentoo developers were unavailable to perform
the necessary modifications to the snapshot creation script
-- for the last 1.5 years -- he kindly sent it to me as a
MIME attachment so that I could "write the code".
Needless to say I was thrilled.
Finally my chance to prove that I am not an idiot, but an
idiot who also contributes to Gentoo!
I managed to software-engineer the necessary "patch" to make
the script generate a full-blown GPG signature for the
snapshot archive, and I would like to post the diffs here so
that the procedure can be peer-reviewed.
So without further ado, here is my contribution:
--- snapshots-create.sh
+++ snapshots-create.sh
@@ -12,7 +12,7 @@
#
# Define locations for stuff
#
-
+SIGNKEYID="41BC28FE99089D72"
MASTER="xxx/xxxxxxxor/rsync" #where the master repository lives
TEMP="/tmp/xxxxxxx/" #working directory
#UPLOAD="/xx/xx/xx/xxx/upload/" #temp location for testing
@@ -42,7 +42,8 @@
/bin/tar --exclude=CVS -cjf ${FILENAME} portage
/usr/bin/md5sum ${FILENAME} > ${FILENAME}.md5sum
-/bin/mv ${FILENAME} ${FILENAME}.md5sum ${UPLOAD}
+/usr/bin/gpg --batch -u "${SIGNKEYID}" --armor --detach-sign --output ${FILENAME}.gpgsig ${FILENAME}
+/bin/mv ${FILENAME} ${FILENAME}.md5sum ${FILENAME}.gpgsig ${UPLOAD}
Now, this is mission-critical software and you really need
to be a top-notch security specialist to do this. So to make
sure there are no problems integrating the script into the
mind-blowingly fragile Gentoo main server setup, I have to
make a few comments to make sure nothing gets messed up
here.
Kurt, I realize that submitting my homework as a diff makes
matters more complicated for you. You have to save that
snippet above to a file and then use the utility patch(1).
If you have _any_ problems with this, please don't hesitate
to let me know, and I'll send you the complete script in
private e-mail.
Before you can use the hardened version of this software,
you have to customize it. Since I have NO ACCESS TO THE
GENTOO SERVERS, the script is tailored for my own system.
The casual readers of this list might want to skip the
following paragraphs, because it's getting really technical
now for a moment.
Everybody else please look closely at the first chunk.
You'll find a line like this:
SIGNKEYID="41BC28FE99089D72"
This statement assigns a variable with the ID of the key
that is going to be used later in the script to generate the
cryptographic signature. I chose to use a variable here so
that the key ID can be configured at the top of the script,
instead of burying that parameter amidst 78 lines of
comments, whitespace, and several complex calls to tar(1)
and other Unix magic. I realize that using a variable adds a
level of indirection which might have performance
implications that are difficult to predict. Kurt, should
this version be too slow to manage the job in time on the
machines, I'll remove that again, okay?
My point about that line is, though: This key ID will NOT
WORK on your machine! The reason is that to issue a
signature, you have to use the secret key of the GPG
key-pair. So although you can download a key with that ID
from every public key server, this will not work! You really
need the secret key.
To make the script work nonetheless you have to:
(1) Start appropriate text editing software. On most Gentoo
machines, the tool nano(1) can be used for this.
(2) Repeatedly hit the cursor-down button on your keyboard
until that white rectangle you're seeing is right over
that SIGNKEYID line from above.
(3) Stop hitting cursor-down now!
(4) If the white rectangle has moved past that line
already, then you have to hit CTRL-Z, then enter
kill -9 %1
and go back to step (1) and try again.
(5) Don't give up.
(6) If you have successfully navigated the white rectangle
to the line, hit cursor-right repeatedly until it has
reached the point right after the first double quote.
(7) Don't give up.
(8) Switch into overwrite mode and enter the ID of your
secret key.
(9) Save the modified script and exit the text editing
software. I'd love to give more details on this step,
but unfortunately the exact procedure is implementation
defined.
After you have successfully edited the key ID to match the
one your secret key has, you should be ready to try it out.
Just enter "snapshots-create.sh" and see what happens.
What do you mean it doesn't work?
Hmmm. Does "./snapshots-create.sh" work?
Doesn't either?
Hmmm. Ah, wait. Enter "chmod +x snapshots-create.sh".
Good, now run the "./snapshots-create.sh" command again.
STILL doesn't work?
What does it say on the screen?
Nothing?
Hahaha, now I got it. No, no, that's perfectly alright. It
will take a while for the script to return; that thing runs
a while. Yes, security-related software does require lots
and lots of CPU time; that really can't be helped in any
way, so please be patient.
Now, if the script has returned at last you will find the
following files in the Gentoo download area:
portage-20041109.tar.bz2
portage-20041109.tar.bz2.gpgsig
portage-20041109.tar.bz2.md5sum
Don't be concerned if the filenames don't match exactly.
These numbers depend on the t-coordinate of the system the
script is run on; that is a kind of unique hash to guarantee
that no filename collisions occur.
If this has succeeded, then you have a TOTALLY secure Gentoo
distribution now; there really is nothing left to worry
about.
Just execute "emerge sync", wait until it comes back and ...
everything still works, no hacker has injected any modified
/usr/portage/eclass/eutils.eclass file into your machine,
you are totally SAFE!
Of course, I wouldn't install any new software for the next
1.5 years because there remains a small, insignificant
chance that doing this will erase your hard disk, install
Red Hat Linux, or do other horrible things.
But you know how the old saying goes: Never change a running
system!
Exactly.
WARNING *** WARNING *** WARNING *** WARNING
My instructions have been written for the final version of
this hardening mechanism. Right now, the "totally secure"
bit is not quite accurate because I still haven't gotten to
"patch" any of the Gentoo tools to verify that signature.
Or, to be perfectly honest, I have gotten to but didn't
manage.
There is some complexity to the task that wasn't quite
understood when I agreed to do all this for Gentoo, because
before I can call GPG to verify the signature, I have to
execute
source /etc/make.conf
to import some more variables, so that the user can
switch authentication on/off, set the path to the official
Gentoo key and all that. And frankly, it is just too damn
difficult.
Anyway, I promise I will do that ASAP. Let's see ... we have
2004 now ... Man, that is gonna take a while. Because, as it
happens, I have other stuff to do, too, you know? It's not
like I am getting paid for all this!
And besides: I simply don't give a shit.
Cheers,
Peter
--
gentoo-security@gentoo.org mailing list
I am very proud to announce that I have managed to perform
the crucial security fix assignment I have been given by
Kurt Lieber and Dan Margolis. After I had kissed some ass,
publicly humiliated myself, and swallowed a couple of dozen
insults, I was deemed worthy enough to do what Kurt referred
to as "to work with [him] to help [finding] ways to fix it".
For various reasons which he didn't bother to elaborate on
the public mailing list -- probably for good reason --, it
turned out that my suggested solution to the fact that
Gentoo users all over the Internet are completely
defenseless against man-in-the-middle attacks was considered
absolutely unfeasible.
So he informed me that the ONLY WAY to do anything against
that little glitch is to sign the daily Portage snapshot
that's available for download with "emerge-webrsync". This
does protect a flabbergasting total of ... I dunno ... maybe
.1 percent of the user base, so it is better than nothing.
Since all the Gentoo developers were unavailable to perform
the necessary modifications to the snapshot creation script
-- for the last 1.5 years -- he kindly sent it to me as a
MIME attachment so that I could "write the code".
Needless to say I was thrilled.
Finally my chance to prove that I am not an idiot, but an
idiot who also contributes to Gentoo!
I managed to software-engineer the necessary "patch" to make
the script generate a full-blown GPG signature for the
snapshot archive, and I would like to post the diffs here so
that the procedure can be peer-reviewed.
So without further ado, here is my contribution:
--- snapshots-create.sh
+++ snapshots-create.sh
@@ -12,7 +12,7 @@
#
# Define locations for stuff
#
-
+SIGNKEYID="41BC28FE99089D72"
MASTER="xxx/xxxxxxxor/rsync" #where the master repository lives
TEMP="/tmp/xxxxxxx/" #working directory
#UPLOAD="/xx/xx/xx/xxx/upload/" #temp location for testing
@@ -42,7 +42,8 @@
/bin/tar --exclude=CVS -cjf ${FILENAME} portage
/usr/bin/md5sum ${FILENAME} > ${FILENAME}.md5sum
-/bin/mv ${FILENAME} ${FILENAME}.md5sum ${UPLOAD}
+/usr/bin/gpg --batch -u "${SIGNKEYID}" --armor --detach-sign --output ${FILENAME}.gpgsig ${FILENAME}
+/bin/mv ${FILENAME} ${FILENAME}.md5sum ${FILENAME}.gpgsig ${UPLOAD}
Now, this is mission-critical software and you really need
to be a top-notch security specialist to do this. So to make
sure there are no problems integrating the script into the
mind-blowingly fragile Gentoo main server setup, I have to
make a few comments to make sure nothing gets messed up
here.
Kurt, I realize that submitting my homework as a diff makes
matters more complicated for you. You have to save that
snippet above to a file and then use the utility patch(1).
If you have _any_ problems with this, please don't hesitate
to let me know, and I'll send you the complete script in
private e-mail.
Before you can use the hardened version of this software,
you have to customize it. Since I have NO ACCESS TO THE
GENTOO SERVERS, the script is tailored for my own system.
The casual readers of this list might want to skip the
following paragraphs, because it's getting really technical
now for a moment.
Everybody else please look closely at the first chunk.
You'll find a line like this:
SIGNKEYID="41BC28FE99089D72"
This statement assigns a variable with the ID of the key
that is going to be used later in the script to generate the
cryptographic signature. I chose to use a variable here so
that the key ID can be configured at the top of the script,
instead of burying that parameter amidst 78 lines of
comments, whitespace, and several complex calls to tar(1)
and other Unix magic. I realize that using a variable adds a
level of indirection which might have performance
implications that are difficult to predict. Kurt, should
this version be too slow to manage the job in time on the
machines, I'll remove that again, okay?
My point about that line is, though: This key ID will NOT
WORK on your machine! The reason is that to issue a
signature, you have to use the secret key of the GPG
key-pair. So although you can download a key with that ID
from every public key server, this will not work! You really
need the secret key.
To make the script work nonetheless you have to:
(1) Start appropriate text editing software. On most Gentoo
machines, the tool nano(1) can be used for this.
(2) Repeatedly hit the cursor-down button on your keyboard
until that white rectangle you're seeing is right over
that SIGNKEYID line from above.
(3) Stop hitting cursor-down now!
(4) If the white rectangle has moved past that line
already, then you have to hit CTRL-Z, then enter
kill -9 %1
and go back to step (1) and try again.
(5) Don't give up.
(6) If you have successfully navigated the white rectangle
to the line, hit cursor-right repeatedly until it has
reached the point right after the first double quote.
(7) Don't give up.
(8) Switch into overwrite mode and enter the ID of your
secret key.
(9) Save the modified script and exit the text editing
software. I'd love to give more details on this step,
but unfortunately the exact procedure is implementation
defined.
After you have successfully edited the key ID to match the
one your secret key has, you should be ready to try it out.
Just enter "snapshots-create.sh" and see what happens.
What do you mean it doesn't work?
Hmmm. Does "./snapshots-create.sh" work?
Doesn't either?
Hmmm. Ah, wait. Enter "chmod +x snapshots-create.sh".
Good, now run the "./snapshots-create.sh" command again.
STILL doesn't work?
What does it say on the screen?
Nothing?
Hahaha, now I got it. No, no, that's perfectly alright. It
will take a while for the script to return; that thing runs
a while. Yes, security-related software does require lots
and lots of CPU time; that really can't be helped in any
way, so please be patient.
Now, if the script has returned at last you will find the
following files in the Gentoo download area:
portage-20041109.tar.bz2
portage-20041109.tar.bz2.gpgsig
portage-20041109.tar.bz2.md5sum
Don't be concerned if the filenames don't match exactly.
These numbers depend on the t-coordinate of the system the
script is run on; that is a kind of unique hash to guarantee
that no filename collisions occur.
If this has succeeded, then you have a TOTALLY secure Gentoo
distribution now; there really is nothing left to worry
about.
Just execute "emerge sync", wait until it comes back and ...
everything still works, no hacker has injected any modified
/usr/portage/eclass/eutils.eclass file into your machine,
you are totally SAFE!
Of course, I wouldn't install any new software for the next
1.5 years because there remains a small, insignificant
chance that doing this will erase your hard disk, install
Red Hat Linux, or do other horrible things.
But you know how the old saying goes: Never change a running
system!
Exactly.
WARNING *** WARNING *** WARNING *** WARNING
My instructions have been written for the final version of
this hardening mechanism. Right now, the "totally secure"
bit is not quite accurate because I still haven't gotten to
"patch" any of the Gentoo tools to verify that signature.
Or, to be perfectly honest, I have gotten to but didn't
manage.
There is some complexity to the task that wasn't quite
understood when I agreed to do all this for Gentoo, because
before I can call GPG to verify the signature, I have to
execute
source /etc/make.conf
to import some more variables, so that the user can
switch authentication on/off, set the path to the official
Gentoo key and all that. And frankly, it is just too damn
difficult.
Anyway, I promise I will do that ASAP. Let's see ... we have
2004 now ... Man, that is gonna take a while. Because, as it
happens, I have other stuff to do, too, you know? It's not
like I am getting paid for all this!
And besides: I simply don't give a shit.
Cheers,
Peter
--
gentoo-security@gentoo.org mailing list