Re: Debian audititing tool?
On Wed, Dec 27, 2000 at 11:12:28AM +0100, Christian Kurz wrote: > > You probably misconfigured your mutt. > > No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has > the correct "Mail-Copies-To: never", which means that I don't want any > copies of the answers. you still need to fix your Mail-Followup-To to reflect this as well. its really quite simple just change `lists' to `subscribe' in your ~/.muttrc. i know your using lists since mutt does not even add a Mail-Followup-To otherwise. the only difference between lists and subscribe is the former requests you be CCed, while the latter does not. right now your mutt configuration causes mutt list reply to CC you. this is mutt in potato r2. i would suggest fixing it if you really don't want CCs because your going to get them regardless of that Mail-Copies-To. /me manually has to remove Christian's address from the CC line. and won't do it next time. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpQHgZ6UiIoG.pgp Description: PGP signature
Re: Debian audititing tool?
On Wed, Dec 27, 2000 at 11:12:28AM +0100, Christian Kurz wrote: > > You probably misconfigured your mutt. > > No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has > the correct "Mail-Copies-To: never", which means that I don't want any > copies of the answers. you still need to fix your Mail-Followup-To to reflect this as well. its really quite simple just change `lists' to `subscribe' in your ~/.muttrc. i know your using lists since mutt does not even add a Mail-Followup-To otherwise. the only difference between lists and subscribe is the former requests you be CCed, while the latter does not. right now your mutt configuration causes mutt list reply to CC you. this is mutt in potato r2. i would suggest fixing it if you really don't want CCs because your going to get them regardless of that Mail-Copies-To. /me manually has to remove Christian's address from the CC line. and won't do it next time. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Debian audititing tool?
Hi Christian! On Wed, 27 Dec 2000, Christian Kurz wrote: > > You probably misconfigured your mutt. > > No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has > the correct "Mail-Copies-To: never", which means that I don't want any > copies of the answers. Your mail followup2 header is still broken: | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, | debian-security@lists.debian.org Correcting it might save you a lot of unwanted messages. Btw, is there a reason you did not honor my MailFup2Header? yours, peter PS: your fup2header ignored -- PGP signed and encrypted messages preferred. http://www.palfrader.org/
Re: Debian audititing tool?
On 00-12-27 Peter Palfrader wrote: > On Wed, 27 Dec 2000, Christian Kurz wrote: > > On 00-12-27 David Wright wrote: > > > Quoting Christian Kurz ([EMAIL PROTECTED]): > > > > [ Stop sending me unnecessary Ccs.] > > > | Date: Tue, 26 Dec 2000 16:02:30 +0100 > > > | From: Christian Kurz <[EMAIL PROTECTED]> > > > | To: debian-security@lists.debian.org > > > | Subject: Re: Debian audititing tool? > > > | Message-ID: <[EMAIL PROTECTED]> > > > | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, > > > | debian-security@lists.debian.org > > > > > I must be missing something here. You're the second person in > > > about as many days to ask for people not to send Ccs while > > > including a mail-followup-to: header for their own address. > > > > > What is the latter intended to do? > > > > I suspect that smartlist is playing here with the header as I normally > > set a "Mail-Followup-To: nobody". So you maybe should contact the > > listmaster for more information about this. (And stop those damn Ccs.) > Mail-Followup-To: nobody is really wrong[TM]. Mail-Followup-To: should > be debian-security@lists.debian.org on this list if you don't want CCs. > You probably misconfigured your mutt. No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has the correct "Mail-Copies-To: never", which means that I don't want any copies of the answers. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
Hi Christian! On Wed, 27 Dec 2000, Christian Kurz wrote: > On 00-12-27 David Wright wrote: > > Quoting Christian Kurz ([EMAIL PROTECTED]): > > > [ Stop sending me unnecessary Ccs.] > > | Date: Tue, 26 Dec 2000 16:02:30 +0100 > > | From: Christian Kurz <[EMAIL PROTECTED]> > > | To: debian-security@lists.debian.org > > | Subject: Re: Debian audititing tool? > > | Message-ID: <[EMAIL PROTECTED]> > > | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, > > | debian-security@lists.debian.org > > > I must be missing something here. You're the second person in > > about as many days to ask for people not to send Ccs while > > including a mail-followup-to: header for their own address. > > > What is the latter intended to do? > > I suspect that smartlist is playing here with the header as I normally > set a "Mail-Followup-To: nobody". So you maybe should contact the > listmaster for more information about this. (And stop those damn Ccs.) Mail-Followup-To: nobody is really wrong[TM]. Mail-Followup-To: should be debian-security@lists.debian.org on this list if you don't want CCs. You probably misconfigured your mutt. in your muttrc: set followup_to # Add Mail-Followup-To header. And then: lists debian-security@lists.debian.org # Sets Followup2header: list, you subscribe debian-security@lists.debian.org # Sets Fup2header: list only choose one. No need to munge the mailfup2 header yourself. yours, peter -- PGP signed and encrypted messages preferred. http://www.palfrader.org/
Re: Debian audititing tool?
On 00-12-27 David Wright wrote: > Quoting Christian Kurz ([EMAIL PROTECTED]): > > [ Stop sending me unnecessary Ccs.] > | Date: Tue, 26 Dec 2000 16:02:30 +0100 > | From: Christian Kurz <[EMAIL PROTECTED]> > | To: debian-security@lists.debian.org > | Subject: Re: Debian audititing tool? > | Message-ID: <[EMAIL PROTECTED]> > | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, > | debian-security@lists.debian.org > I must be missing something here. You're the second person in > about as many days to ask for people not to send Ccs while > including a mail-followup-to: header for their own address. > What is the latter intended to do? I suspect that smartlist is playing here with the header as I normally set a "Mail-Followup-To: nobody". So you maybe should contact the listmaster for more information about this. (And stop those damn Ccs.) Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
Quoting Christian Kurz ([EMAIL PROTECTED]): > [ Stop sending me unnecessary Ccs.] > | Date: Tue, 26 Dec 2000 16:02:30 +0100 | From: Christian Kurz <[EMAIL PROTECTED]> | To: debian-security@lists.debian.org | Subject: Re: Debian audititing tool? | Message-ID: <[EMAIL PROTECTED]> | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, | debian-security@lists.debian.org I must be missing something here. You're the second person in about as many days to ask for people not to send Ccs while including a mail-followup-to: header for their own address. What is the latter intended to do? Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised.
Re: Debian audititing tool?
Hi Christian! On Wed, 27 Dec 2000, Christian Kurz wrote: > > You probably misconfigured your mutt. > > No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has > the correct "Mail-Copies-To: never", which means that I don't want any > copies of the answers. Your mail followup2 header is still broken: | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, | [EMAIL PROTECTED] Correcting it might save you a lot of unwanted messages. Btw, is there a reason you did not honor my MailFup2Header? yours, peter PS: your fup2header ignored -- PGP signed and encrypted messages preferred. http://www.palfrader.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-27 Peter Palfrader wrote: > On Wed, 27 Dec 2000, Christian Kurz wrote: > > On 00-12-27 David Wright wrote: > > > Quoting Christian Kurz ([EMAIL PROTECTED]): > > > > [ Stop sending me unnecessary Ccs.] > > > | Date: Tue, 26 Dec 2000 16:02:30 +0100 > > > | From: Christian Kurz <[EMAIL PROTECTED]> > > > | To: [EMAIL PROTECTED] > > > | Subject: Re: Debian audititing tool? > > > | Message-ID: <[EMAIL PROTECTED]> > > > | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, > > > | [EMAIL PROTECTED] > > > > > I must be missing something here. You're the second person in > > > about as many days to ask for people not to send Ccs while > > > including a mail-followup-to: header for their own address. > > > > > What is the latter intended to do? > > > > I suspect that smartlist is playing here with the header as I normally > > set a "Mail-Followup-To: nobody". So you maybe should contact the > > listmaster for more information about this. (And stop those damn Ccs.) > Mail-Followup-To: nobody is really wrong[TM]. Mail-Followup-To: should > be [EMAIL PROTECTED] on this list if you don't want CCs. > You probably misconfigured your mutt. No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has the correct "Mail-Copies-To: never", which means that I don't want any copies of the answers. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Hi Christian! On Wed, 27 Dec 2000, Christian Kurz wrote: > On 00-12-27 David Wright wrote: > > Quoting Christian Kurz ([EMAIL PROTECTED]): > > > [ Stop sending me unnecessary Ccs.] > > | Date: Tue, 26 Dec 2000 16:02:30 +0100 > > | From: Christian Kurz <[EMAIL PROTECTED]> > > | To: [EMAIL PROTECTED] > > | Subject: Re: Debian audititing tool? > > | Message-ID: <[EMAIL PROTECTED]> > > | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, > > | [EMAIL PROTECTED] > > > I must be missing something here. You're the second person in > > about as many days to ask for people not to send Ccs while > > including a mail-followup-to: header for their own address. > > > What is the latter intended to do? > > I suspect that smartlist is playing here with the header as I normally > set a "Mail-Followup-To: nobody". So you maybe should contact the > listmaster for more information about this. (And stop those damn Ccs.) Mail-Followup-To: nobody is really wrong[TM]. Mail-Followup-To: should be [EMAIL PROTECTED] on this list if you don't want CCs. You probably misconfigured your mutt. in your muttrc: set followup_to # Add Mail-Followup-To header. And then: lists [EMAIL PROTECTED] # Sets Followup2header: list, you subscribe [EMAIL PROTECTED] # Sets Fup2header: list only choose one. No need to munge the mailfup2 header yourself. yours, peter -- PGP signed and encrypted messages preferred. http://www.palfrader.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-27 David Wright wrote: > Quoting Christian Kurz ([EMAIL PROTECTED]): > > [ Stop sending me unnecessary Ccs.] > | Date: Tue, 26 Dec 2000 16:02:30 +0100 > | From: Christian Kurz <[EMAIL PROTECTED]> > | To: [EMAIL PROTECTED] > | Subject: Re: Debian audititing tool? > | Message-ID: <[EMAIL PROTECTED]> > | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, > | [EMAIL PROTECTED] > I must be missing something here. You're the second person in > about as many days to ask for people not to send Ccs while > including a mail-followup-to: header for their own address. > What is the latter intended to do? I suspect that smartlist is playing here with the header as I normally set a "Mail-Followup-To: nobody". So you maybe should contact the listmaster for more information about this. (And stop those damn Ccs.) Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Quoting Christian Kurz ([EMAIL PROTECTED]): > [ Stop sending me unnecessary Ccs.] > | Date: Tue, 26 Dec 2000 16:02:30 +0100 | From: Christian Kurz <[EMAIL PROTECTED]> | To: [EMAIL PROTECTED] | Subject: Re: Debian audititing tool? | Message-ID: <[EMAIL PROTECTED]> | Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, | [EMAIL PROTECTED] I must be missing something here. You're the second person in about as many days to ask for people not to send Ccs while including a mail-followup-to: header for their own address. What is the latter intended to do? Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-26 Rainer Weikusat wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > > Debsums seems to help a little bit - you can expect to catch some > > > less-clueful > > > intruders with it, but it doesn't help in general. > > > > debsums just uses md5sums which can be manipulated on the one hand and > > on the other hand you modify binaries so that the md5sum will still be > > the same. > So you've effectively broken MD5 in a way that would yield useful > results (ie would allow you to replace a specific binary with another > specific binary, not with some more or less random garbage). How came > it that you weren't prominently mentionend in this month's cryptogram? Small adnotation to this: If someone would have read the whole discussion about this, he would have found my explanation of this statement. But seems like some people always read only some mails and then make their assumptions. :( Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpAhSjK93xze.pgp Description: PGP signature
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 10:52:47PM +0100, Christian Kurz wrote: > On 00-12-26 Peter Cordes wrote: > > have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't > > a real break against MD5. It means that you can find two messages that hash > > to the same value. To do so, you _have_ to choose both messages yourself. > > If one of the messages is /bin/su, you are almost certainly out of luck. > > Nobody has figured out how to make another message that collides with a > > given message. It only works if they create _both_ messages. > > Cool, would you then please explain why Bruce Schneier writes about MD5: > "I am wary of using MD5" in his book "Applied Cryptograhy" and the end > of the section about MD5? > > Ciao > Christian > For some applications the collision-resistance property is critical. Simply computing and storing one-way hashes IS NOT an application which depends on this property. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- dg
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 09:27:53PM +0200, Pavel Minev Penev wrote: > On Tue, Dec 26, 2000 at 05:27:07PM +0300, [EMAIL PROTECTED] wrote: > > Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for > > binaries. Tampering with MAC database is useless. > > > > ... > > > > [1] Message Authentication Code. One of possible ways to compute MAC is > > H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, > > M > > is message (protected binary). > > Hey, I'm not very good at crypto; however, I was wondering what prevents the > intruder from regenerating the MAC data-base (and what is the point of the > double hashing you have stated as "H(K,H(K,M))"?). > The Book (Bruce Schneier, "Applied Cryptography"): Alice concatenates K and M, and computes the one-way hash of concatenation: H(K,M). This hash is the MAC. Since Bob knows K, he can reproduce Alice's result. Mallory, who does not know K, can't. This method works with MD-strengtheninig techniques, but has serious problems. Malory can always add new blocks to the end of message and compute a valid MAC. This attack can be thwarted if you put the message length at the beginning, but Preneel is suspictios of this scheme. It is better to put the key at then end of message, H(M,K), but this has some problems as well. The following constructions seem secure: H(K1,H(K2,M)) H(K,H(K,M)) H(K,p,M,K), where p pads K to full message block. > Sorry if off-topic (though a nice critical note would be fine). > > And don't forget to be gay (at least on Christmas), > -- > Pavel M. Penev > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- dg
Re: Debian audititing tool?
On 00-12-26 Peter Cordes wrote: > have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't > a real break against MD5. It means that you can find two messages that hash > to the same value. To do so, you _have_ to choose both messages yourself. > If one of the messages is /bin/su, you are almost certainly out of luck. > Nobody has figured out how to make another message that collides with a > given message. It only works if they create _both_ messages. Cool, would you then please explain why Bruce Schneier writes about MD5: "I am wary of using MD5" in his book "Applied Cryptograhy" and the end of the section about MD5? Ciao Christian
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 05:37:54PM +0100, Christian Kurz wrote: > On 00-12-26 Rainer Weikusat wrote: > > Christian Kurz <[EMAIL PROTECTED]> writes: > > ... blah blah blah ... Let's stop arguing about this. Instead of flaming anyone, I'll try to state the relevant facts, since this argument is only happening because not all of us are aware of them. Christian, you've pointed out that people have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't a real break against MD5. It means that you can find two messages that hash to the same value. To do so, you _have_ to choose both messages yourself. If one of the messages is /bin/su, you are almost certainly out of luck. Nobody has figured out how to make another message that collides with a given message. It only works if they create _both_ messages. > > > | and on the other hand you modify binaries so that the md5sum will > > | still be the same. > > > > While this doesn't make any sense in the given context (see above), > > I'd translate it to: "Man kann ein binary so verändern, daß der > > MD5-Hash gleich bleibt." I don't know German, sorry, but I think we are all interpreting the statement as: it is possible to modify e.g. /bin/su so that the MD5 hash of it will be the same, without attacking the place where the known-good hash values are stored. > > Why do you think that it doesn't make any sense? It makes sense, but it is a bold claim. As I said above, nobody has done this yet, and if they did, it would put MD5 in the same league as CRC, a useful error-detection code, but not a cryptographically secure hash. It would allow attacks on a whole lot of stuff that uses MD5 as a secure hash. As things are now, nobody has broken MD5. It has been shown that MD5 has weaknesses, which means it isn't as strong as it was supposed to be, and gives hope (or fear!) that it might be breakable. For new designs, it is probably a good idea to use something other than MD5, but MD5 is currently safe. Migrating to something stronger is probably a good idea if it can be done easily. > > So, either reformulate that in the way you really meant it or give > > some evidence to support it or put your head into a bathtub filled > > with cold water and try to cool of or little. > > As I wrote in my previous mail. If you want to flame someone, search for > a better target. EOD. I think you deserved that flame. You did claim that MD5 had been broken, but no break of this variety has been published, by you or anyone else. However, I think this was due to an an honest mistake on your part, since most people spend their time getting other stuff done, instead of learning about crypto. (If I screwed up any facts in the above, somebody please correct me. If I didn't, then I don't think there is anything more to flame anyone about, except me, for being so presumptuous as to try to cut off a flame war!) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Debian audititing tool?
On 00-12-26 Rainer Weikusat wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > > Debsums seems to help a little bit - you can expect to catch some less-clueful > > > intruders with it, but it doesn't help in general. > > > > debsums just uses md5sums which can be manipulated on the one hand and > > on the other hand you modify binaries so that the md5sum will still be > > the same. > So you've effectively broken MD5 in a way that would yield useful > results (ie would allow you to replace a specific binary with another > specific binary, not with some more or less random garbage). How came > it that you weren't prominently mentionend in this month's cryptogram? Small adnotation to this: If someone would have read the whole discussion about this, he would have found my explanation of this statement. But seems like some people always read only some mails and then make their assumptions. :( Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 10:52:47PM +0100, Christian Kurz wrote: > On 00-12-26 Peter Cordes wrote: > > have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't > > a real break against MD5. It means that you can find two messages that hash > > to the same value. To do so, you _have_ to choose both messages yourself. > > If one of the messages is /bin/su, you are almost certainly out of luck. > > Nobody has figured out how to make another message that collides with a > > given message. It only works if they create _both_ messages. > > Cool, would you then please explain why Bruce Schneier writes about MD5: > "I am wary of using MD5" in his book "Applied Cryptograhy" and the end > of the section about MD5? > > Ciao > Christian > For some applications the collision-resistance property is critical. Simply computing and storing one-way hashes IS NOT an application which depends on this property. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 09:27:53PM +0200, Pavel Minev Penev wrote: > On Tue, Dec 26, 2000 at 05:27:07PM +0300, [EMAIL PROTECTED] wrote: > > Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for > > binaries. Tampering with MAC database is useless. > > > > ... > > > > [1] Message Authentication Code. One of possible ways to compute MAC is > > H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, M > > is message (protected binary). > > Hey, I'm not very good at crypto; however, I was wondering what prevents the > intruder from regenerating the MAC data-base (and what is the point of the > double hashing you have stated as "H(K,H(K,M))"?). > The Book (Bruce Schneier, "Applied Cryptography"): Alice concatenates K and M, and computes the one-way hash of concatenation: H(K,M). This hash is the MAC. Since Bob knows K, he can reproduce Alice's result. Mallory, who does not know K, can't. This method works with MD-strengtheninig techniques, but has serious problems. Malory can always add new blocks to the end of message and compute a valid MAC. This attack can be thwarted if you put the message length at the beginning, but Preneel is suspictios of this scheme. It is better to put the key at then end of message, H(M,K), but this has some problems as well. The following constructions seem secure: H(K1,H(K2,M)) H(K,H(K,M)) H(K,p,M,K), where p pads K to full message block. > Sorry if off-topic (though a nice critical note would be fine). > > And don't forget to be gay (at least on Christmas), > -- > Pavel M. Penev > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-26 Peter Cordes wrote: > have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't > a real break against MD5. It means that you can find two messages that hash > to the same value. To do so, you _have_ to choose both messages yourself. > If one of the messages is /bin/su, you are almost certainly out of luck. > Nobody has figured out how to make another message that collides with a > given message. It only works if they create _both_ messages. Cool, would you then please explain why Bruce Schneier writes about MD5: "I am wary of using MD5" in his book "Applied Cryptograhy" and the end of the section about MD5? Ciao Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 05:27:07PM +0300, [EMAIL PROTECTED] wrote: > Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for > binaries. Tampering with MAC database is useless. > > ... > > [1] Message Authentication Code. One of possible ways to compute MAC is > H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, M > is message (protected binary). Hey, I'm not very good at crypto; however, I was wondering what prevents the intruder from regenerating the MAC data-base (and what is the point of the double hashing you have stated as "H(K,H(K,M))"?). Sorry if off-topic (though a nice critical note would be fine). And don't forget to be gay (at least on Christmas), -- Pavel M. Penev
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 05:37:54PM +0100, Christian Kurz wrote: > On 00-12-26 Rainer Weikusat wrote: > > Christian Kurz <[EMAIL PROTECTED]> writes: > > ... blah blah blah ... Let's stop arguing about this. Instead of flaming anyone, I'll try to state the relevant facts, since this argument is only happening because not all of us are aware of them. Christian, you've pointed out that people have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't a real break against MD5. It means that you can find two messages that hash to the same value. To do so, you _have_ to choose both messages yourself. If one of the messages is /bin/su, you are almost certainly out of luck. Nobody has figured out how to make another message that collides with a given message. It only works if they create _both_ messages. > > > | and on the other hand you modify binaries so that the md5sum will > > | still be the same. > > > > While this doesn't make any sense in the given context (see above), > > I'd translate it to: "Man kann ein binary so verändern, daß der > > MD5-Hash gleich bleibt." I don't know German, sorry, but I think we are all interpreting the statement as: it is possible to modify e.g. /bin/su so that the MD5 hash of it will be the same, without attacking the place where the known-good hash values are stored. > > Why do you think that it doesn't make any sense? It makes sense, but it is a bold claim. As I said above, nobody has done this yet, and if they did, it would put MD5 in the same league as CRC, a useful error-detection code, but not a cryptographically secure hash. It would allow attacks on a whole lot of stuff that uses MD5 as a secure hash. As things are now, nobody has broken MD5. It has been shown that MD5 has weaknesses, which means it isn't as strong as it was supposed to be, and gives hope (or fear!) that it might be breakable. For new designs, it is probably a good idea to use something other than MD5, but MD5 is currently safe. Migrating to something stronger is probably a good idea if it can be done easily. > > So, either reformulate that in the way you really meant it or give > > some evidence to support it or put your head into a bathtub filled > > with cold water and try to cool of or little. > > As I wrote in my previous mail. If you want to flame someone, search for > a better target. EOD. I think you deserved that flame. You did claim that MD5 had been broken, but no break of this variety has been published, by you or anyone else. However, I think this was due to an an honest mistake on your part, since most people spend their time getting other stuff done, instead of learning about crypto. (If I screwed up any facts in the above, somebody please correct me. If I didn't, then I don't think there is anything more to flame anyone about, except me, for being so presumptuous as to try to cut off a flame war!) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 05:27:07PM +0300, [EMAIL PROTECTED] wrote: > Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for > binaries. Tampering with MAC database is useless. > > ... > > [1] Message Authentication Code. One of possible ways to compute MAC is > H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, M > is message (protected binary). Hey, I'm not very good at crypto; however, I was wondering what prevents the intruder from regenerating the MAC data-base (and what is the point of the double hashing you have stated as "H(K,H(K,M))"?). Sorry if off-topic (though a nice critical note would be fine). And don't forget to be gay (at least on Christmas), -- Pavel M. Penev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-26 Rainer Weikusat wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > [ Stop sending me unnecessary Ccs.] > Start thinking about getting a decent mail client. My client is so decent, that it support a pure list-reply-function. Looks like your client is missing such a feature. > > > > and on the other hand you modify binaries so that the md5sum will > > > > still be the same. > > > > > So you've effectively broken MD5 in a way that would yield useful > > > results > [...] > > Why don't you get a clue and write again what I wrote? > Why don't you try this in German if your English is obviously to > lacking to make any sense at all? Strange. The other readers on this list had no problem in understand my mail. So, you may just be missing a "can", but if this the cause for your misunderstanding, I suggest that your parser is broken. > > Here's a small hint: Does the author talks about himself or > > everybody? > Here's a small hint: > | and on the other hand you modify binaries so that the md5sum will > | still be the same. > > While this doesn't make any sense in the given context (see above), > I'd translate it to: "Man kann ein binary so verändern, daß der > MD5-Hash gleich bleibt." Why do you think that it doesn't make any sense? > So, either reformulate that in the way you really meant it or give > some evidence to support it or put your head into a bathtub filled > with cold water and try to cool of or little. As I wrote in my previous mail. If you want to flame someone, search for a better target. EOD.
Re: Debian audititing tool?
Christian Kurz <[EMAIL PROTECTED]> writes: > [ Stop sending me unnecessary Ccs.] Start thinking about getting a decent mail client. > > > and on the other hand you modify binaries so that the md5sum will > > > still be the same. > > > So you've effectively broken MD5 in a way that would yield useful > > results [...] > Why don't you get a clue and write again what I wrote? Why don't you try this in German if your English is obviously to lacking to make any sense at all? > Here's a small hint: Does the author talks about himself or > everybody? Here's a small hint: | and on the other hand you modify binaries so that the md5sum will | still be the same. While this doesn't make any sense in the given context (see above), I'd translate it to: "Man kann ein binary so verändern, daß der MD5-Hash gleich bleibt." This, as it stands, I'd call a rather bold claim. So, either reformulate that in the way you really meant it or give some evidence to support it or put your head into a bathtub filled with cold water and try to cool of or little. -- SIGSTOP
Re: Debian audititing tool?
[ Stop sending me unnecessary Ccs.] On 00-12-26 Rainer Weikusat wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > > Debsums seems to help a little bit - you can expect to catch some > > > less-clueful intruders with it, but it doesn't help in general. > > > > debsums just uses md5sums which can be manipulated on the one hand > > and on the other hand you modify binaries so that the md5sum will > > still be the same. > So you've effectively broken MD5 in a way that would yield useful > results (ie would allow you to replace a specific binary with another > specific binary, not with some more or less random garbage). How came > it that you weren't prominently mentionend in this month's cryptogram? Why don't you get a clue and write again what I wrote? Here's a small hint: Does the author talks about himself or everybody? If you just want to do a bit of flaming then you should use someone else as your target. If not, I assume you haven't read the whole thread. Do this and then come back again. Ciao Christian
Re: Debian audititing tool?
Christian Kurz <[EMAIL PROTECTED]> writes: > > Debsums seems to help a little bit - you can expect to catch some > > less-clueful > > intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand and > on the other hand you modify binaries so that the md5sum will still be > the same. So you've effectively broken MD5 in a way that would yield useful results (ie would allow you to replace a specific binary with another specific binary, not with some more or less random garbage). How came it that you weren't prominently mentionend in this month's cryptogram? -- SIGSTOP
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote: > > Debsums seems to help a little bit - you can expect to catch some > > less-clueful > > intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand and > on the other hand you modify binaries so that the md5sum will still be > the same. > Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for binaries. Tampering with MAC database is useless. Of coures we should be sure that checking programm is not tampered, the only possible way to insure is to run it from readonly media (CDROM). We should not store MAC key on system, it should be computed from user entered passphrase. We can avoid burning new CDROM each time we install or upgrade software. New CDROM is only needed when we upgrade checking program, in any other case we only need to update MAC database. [1] Message Authentication Code. One of possible ways to compute MAC is H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, M is message (protected binary). -- dg
Re: Debian audititing tool?
On 00-12-26 Rainer Weikusat wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > [ Stop sending me unnecessary Ccs.] > Start thinking about getting a decent mail client. My client is so decent, that it support a pure list-reply-function. Looks like your client is missing such a feature. > > > > and on the other hand you modify binaries so that the md5sum will > > > > still be the same. > > > > > So you've effectively broken MD5 in a way that would yield useful > > > results > [...] > > Why don't you get a clue and write again what I wrote? > Why don't you try this in German if your English is obviously to > lacking to make any sense at all? Strange. The other readers on this list had no problem in understand my mail. So, you may just be missing a "can", but if this the cause for your misunderstanding, I suggest that your parser is broken. > > Here's a small hint: Does the author talks about himself or > > everybody? > Here's a small hint: > | and on the other hand you modify binaries so that the md5sum will > | still be the same. > > While this doesn't make any sense in the given context (see above), > I'd translate it to: "Man kann ein binary so verändern, daß der > MD5-Hash gleich bleibt." Why do you think that it doesn't make any sense? > So, either reformulate that in the way you really meant it or give > some evidence to support it or put your head into a bathtub filled > with cold water and try to cool of or little. As I wrote in my previous mail. If you want to flame someone, search for a better target. EOD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Christian Kurz <[EMAIL PROTECTED]> writes: > [ Stop sending me unnecessary Ccs.] Start thinking about getting a decent mail client. > > > and on the other hand you modify binaries so that the md5sum will > > > still be the same. > > > So you've effectively broken MD5 in a way that would yield useful > > results [...] > Why don't you get a clue and write again what I wrote? Why don't you try this in German if your English is obviously to lacking to make any sense at all? > Here's a small hint: Does the author talks about himself or > everybody? Here's a small hint: | and on the other hand you modify binaries so that the md5sum will | still be the same. While this doesn't make any sense in the given context (see above), I'd translate it to: "Man kann ein binary so verändern, daß der MD5-Hash gleich bleibt." This, as it stands, I'd call a rather bold claim. So, either reformulate that in the way you really meant it or give some evidence to support it or put your head into a bathtub filled with cold water and try to cool of or little. -- SIGSTOP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
[ Stop sending me unnecessary Ccs.] On 00-12-26 Rainer Weikusat wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > > Debsums seems to help a little bit - you can expect to catch some > > > less-clueful intruders with it, but it doesn't help in general. > > > > debsums just uses md5sums which can be manipulated on the one hand > > and on the other hand you modify binaries so that the md5sum will > > still be the same. > So you've effectively broken MD5 in a way that would yield useful > results (ie would allow you to replace a specific binary with another > specific binary, not with some more or less random garbage). How came > it that you weren't prominently mentionend in this month's cryptogram? Why don't you get a clue and write again what I wrote? Here's a small hint: Does the author talks about himself or everybody? If you just want to do a bit of flaming then you should use someone else as your target. If not, I assume you haven't read the whole thread. Do this and then come back again. Ciao Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Christian Kurz <[EMAIL PROTECTED]> writes: > > Debsums seems to help a little bit - you can expect to catch some less-clueful > > intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand and > on the other hand you modify binaries so that the md5sum will still be > the same. So you've effectively broken MD5 in a way that would yield useful results (ie would allow you to replace a specific binary with another specific binary, not with some more or less random garbage). How came it that you weren't prominently mentionend in this month's cryptogram? -- SIGSTOP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote: > > Debsums seems to help a little bit - you can expect to catch some less-clueful > > intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand and > on the other hand you modify binaries so that the md5sum will still be > the same. > Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for binaries. Tampering with MAC database is useless. Of coures we should be sure that checking programm is not tampered, the only possible way to insure is to run it from readonly media (CDROM). We should not store MAC key on system, it should be computed from user entered passphrase. We can avoid burning new CDROM each time we install or upgrade software. New CDROM is only needed when we upgrade checking program, in any other case we only need to update MAC database. [1] Message Authentication Code. One of possible ways to compute MAC is H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, M is message (protected binary). -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Sat, Dec 23, 2000 at 03:30:08PM -0400, Peter Cordes wrote: > On Fri, Dec 22, 2000 at 11:05:32PM -0900, Ethan Benson wrote: > > On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > > > > > That's why you run the checker from a known-good floppy or CD. The bogus > > > kernel can't protect itself if it isn't running :) > > > > don't be so sure, is the BIOS or firmware on your computer flashable? > > if so an attacker could replace the firmware/BIOS itself to ensure > > later trojans are installed. > > Oh crap, I didn't think of that! It would be a really hard attack if you > didn't know what kernel was going to get loaded, but in theory there's no > way around it, short of burning non-flashable ROMs! (Well, you could take > the drive out of the computer and test it in another computer.) > Yes, this little attack gets bandied about by paranoid people on a regular basis. AFAIK, the only malicious code which has been observed to play with your BIOS is in 'doze virii which nuke it, but don't turn it evil. Although this attack is theoretically possible, it's probably not the weakest link in your security chain. Flashing a BIOS involves quite a bit of effort, and is extremely platform dependent. Do it in a less than perfect way, and spectacular things happen. The odds of doing it without being noticed wouldn't be very good. If you expect that a cracker might pour very large amounts of effort into breaking your system (what *do* you use it for? :), you should read your motherboard manual, and switch the jumpers to disable BIOS flashing. -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgpJhBfaERZrh.pgp Description: PGP signature
Re: Debian audititing tool?
On Sat, Dec 23, 2000 at 03:30:08PM -0400, Peter Cordes wrote: > On Fri, Dec 22, 2000 at 11:05:32PM -0900, Ethan Benson wrote: > > On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > > > > > That's why you run the checker from a known-good floppy or CD. The bogus > > > kernel can't protect itself if it isn't running :) > > > > don't be so sure, is the BIOS or firmware on your computer flashable? > > if so an attacker could replace the firmware/BIOS itself to ensure > > later trojans are installed. > > Oh crap, I didn't think of that! It would be a really hard attack if you > didn't know what kernel was going to get loaded, but in theory there's no > way around it, short of burning non-flashable ROMs! (Well, you could take > the drive out of the computer and test it in another computer.) > Yes, this little attack gets bandied about by paranoid people on a regular basis. AFAIK, the only malicious code which has been observed to play with your BIOS is in 'doze virii which nuke it, but don't turn it evil. Although this attack is theoretically possible, it's probably not the weakest link in your security chain. Flashing a BIOS involves quite a bit of effort, and is extremely platform dependent. Do it in a less than perfect way, and spectacular things happen. The odds of doing it without being noticed wouldn't be very good. If you expect that a cracker might pour very large amounts of effort into breaking your system (what *do* you use it for? :), you should read your motherboard manual, and switch the jumpers to disable BIOS flashing. -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ PGP signature
Re: Debian audititing tool?
On Fri, Dec 22, 2000 at 11:05:32PM -0900, Ethan Benson wrote: > On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > > > That's why you run the checker from a known-good floppy or CD. The bogus > > kernel can't protect itself if it isn't running :) > > don't be so sure, is the BIOS or firmware on your computer flashable? > if so an attacker could replace the firmware/BIOS itself to ensure > later trojans are installed. Oh crap, I didn't think of that! It would be a really hard attack if you didn't know what kernel was going to get loaded, but in theory there's no way around it, short of burning non-flashable ROMs! (Well, you could take the drive out of the computer and test it in another computer.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Debian audititing tool?
On Fri, Dec 22, 2000 at 11:05:32PM -0900, Ethan Benson wrote: > On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > > > That's why you run the checker from a known-good floppy or CD. The bogus > > kernel can't protect itself if it isn't running :) > > don't be so sure, is the BIOS or firmware on your computer flashable? > if so an attacker could replace the firmware/BIOS itself to ensure > later trojans are installed. Oh crap, I didn't think of that! It would be a really hard attack if you didn't know what kernel was going to get loaded, but in theory there's no way around it, short of burning non-flashable ROMs! (Well, you could take the drive out of the computer and test it in another computer.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
> Also with the Debian Firewall/Gibrator?(sorry for the spelling) does > it include SNMP and remote managibility. SNMP will be included in the next version, and a web interface too. At the moment it is fully manageable over ssh. best greets, Rene
Re: Debian audititing tool?
> Also with the Debian Firewall/Gibrator?(sorry for the spelling) does > it include SNMP and remote managibility. SNMP will be included in the next version, and a web interface too. At the moment it is fully manageable over ssh. best greets, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > That's why you run the checker from a known-good floppy or CD. The bogus > kernel can't protect itself if it isn't running :) don't be so sure, is the BIOS or firmware on your computer flashable? if so an attacker could replace the firmware/BIOS itself to ensure later trojans are installed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp7XSWWLUylx.pgp Description: PGP signature
Re: Debian audititing tool?
On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > That's why you run the checker from a known-good floppy or CD. The bogus > kernel can't protect itself if it isn't running :) don't be so sure, is the BIOS or firmware on your computer flashable? if so an attacker could replace the firmware/BIOS itself to ensure later trojans are installed. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Debian audititing tool?
On Sat, Dec 23, 2000 at 10:35:26AM +1300, Carey Evans wrote: > "Dan Hutchinson" <[EMAIL PROTECTED]> writes: > > > Sorry I miss read your response. > > Well you can get the source kernel and run it threw the fornesics program > > then compile it possible. > > Anyway it will help with open trojans and virus anyway. > > There's a couple of things that could go wrong here: > > - gcc could be modified to include a backdoor in the kernel, >something like the way described here: > > http://www.acm.org/classics/sep95/ > > - The trojan could be a Linux kernel module that hides itself from >any system calls that might detect it, substituting innocuous code, >and different MD5 checksums. You can easily find modules like this >quite easily on the web. > That's why you run the checker from a known-good floppy or CD. The bogus kernel can't protect itself if it isn't running :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Debian audititing tool?
"Dan Hutchinson" <[EMAIL PROTECTED]> writes: > Sorry I miss read your response. > Well you can get the source kernel and run it threw the fornesics program > then compile it possible. > Anyway it will help with open trojans and virus anyway. There's a couple of things that could go wrong here: - gcc could be modified to include a backdoor in the kernel, something like the way described here: http://www.acm.org/classics/sep95/ - The trojan could be a Linux kernel module that hides itself from any system calls that might detect it, substituting innocuous code, and different MD5 checksums. You can easily find modules like this quite easily on the web. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "May not be representative of the experience of actual customers."
Re: Debian audititing tool?
"Dan Hutchinson" <[EMAIL PROTECTED]> writes: > Sorry I miss read your response. > Well you can get the source kernel and run it threw the fornesics program > then compile it possible. > Anyway it will help with open trojans and virus anyway. There's a couple of things that could go wrong here: - gcc could be modified to include a backdoor in the kernel, something like the way described here: http://www.acm.org/classics/sep95/ - The trojan could be a Linux kernel module that hides itself from any system calls that might detect it, substituting innocuous code, and different MD5 checksums. You can easily find modules like this quite easily on the web. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "May not be representative of the experience of actual customers." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Sat, Dec 23, 2000 at 10:35:26AM +1300, Carey Evans wrote: > "Dan Hutchinson" <[EMAIL PROTECTED]> writes: > > > Sorry I miss read your response. > > Well you can get the source kernel and run it threw the fornesics program > > then compile it possible. > > Anyway it will help with open trojans and virus anyway. > > There's a couple of things that could go wrong here: > > - gcc could be modified to include a backdoor in the kernel, >something like the way described here: > > http://www.acm.org/classics/sep95/ > > - The trojan could be a Linux kernel module that hides itself from >any system calls that might detect it, substituting innocuous code, >and different MD5 checksums. You can easily find modules like this >quite easily on the web. > That's why you run the checker from a known-good floppy or CD. The bogus kernel can't protect itself if it isn't running :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Jacob Kuntz wrote: > > from the secret journal of Rene Mayrhofer ([EMAIL PROTECTED]): > > http://www.gibaltar.at/ > > is that address correct? i didn't think there was a .at tld, but there are > two 'r's in gibraltar. You are right. Sorry, It was a typo It should read http://www.gibraltar.at/ best greets, Rene
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 08:12:14PM +0100, Christian Kurz wrote: > On 00-12-21 Colin Phipps wrote: > > On Thu, Dec 21, 2000 at 04:09:07PM +0100, Christian Kurz wrote: > > > And who will create this key? Who will have the passphrase? Who will > > > sign the packages? > > > Someone on master.debian.org, presumably the ftp admins. > > And so you trust this admins? Just asking because some people here have > a lot of paranoia. Signing packages on the master mirror guards against compromised or spoofed mirrors. Not trusting the master mirror or its admins is a separate, and much harder problem. -- Colin Phippshttp://www.netcraft.com/
Re: Debian audititing tool?
On 00-12-21 Peter Cordes wrote: > On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > > On 00-12-21 Dan Hutchinson wrote: > > > Sorry it was fornesics, but the code is basically matching the machine > > > code, a unique pattern of 1's and 0's to the machine code of the kernal. > > > > Well, but then you need to know all patterns of malicous code that could > > occur. I think this will be a lot of patterns that you have to search > > for, so that the search will take a long time. > > > > > Unless you have a kernal file that doesn't have 1's and 0's in machine > > > language, you can scan the code. I am not sure how ASM code is written > > > thou. > > > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > > machine-code that is used by the processor. I thaught you wanted to scan > > the code that you find beneath /usr/src/linux. > You have to search the binary kernel image. If you just scan the source, > you have no way of knowing that the binary came from the source. Someone > could hack the binary without changing the source. If there are any > commonly-made changes to the binary, then you could look for them. Agreed, but then you have to scan the modules as well, as someone could change a module too or add one. > It will be hard to do, and impossible to do perfectly. The Right Way is to > keep a hash of your kernel binary so you know if it changes. BTW, md5 has > not been broken, AFAIK, so there is no currently known way to change a > binary without changing its MD5 hash, except trial and error, which would > take a lot more _years_ than anyone would want to wait! You expressed doubt > about this earlier. Rest assured that no real breaks in MD5 have been made > public. (The NSA might have something, but they don't publish.) The md5sum > manpage notes: >The related MD4 message digest algorithm was broken in >October 1995. MD5 isn't looking as secure as it used to. I just looked again in the Schneier to reread the paragraph about MD5. And if you use the compression function in MD5, you can produce collions like den Boer and Boesselaer proofed it. So, you should be careful about the usage of MD5 as Digest Algorithmen, because a "basic design principles [of MD5] - to design a collision-resistant function - has been violated". So I would be very careful about the usage of this algorithmen. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpM3GraaEiwa.pgp Description: PGP signature
Re: Debian audititing tool?
Jacob Kuntz wrote: > > from the secret journal of Rene Mayrhofer ([EMAIL PROTECTED]): > > http://www.gibaltar.at/ > > is that address correct? i didn't think there was a .at tld, but there are > two 'r's in gibraltar. You are right. Sorry, It was a typo It should read http://www.gibraltar.at/ best greets, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 08:12:14PM +0100, Christian Kurz wrote: > On 00-12-21 Colin Phipps wrote: > > On Thu, Dec 21, 2000 at 04:09:07PM +0100, Christian Kurz wrote: > > > And who will create this key? Who will have the passphrase? Who will > > > sign the packages? > > > Someone on master.debian.org, presumably the ftp admins. > > And so you trust this admins? Just asking because some people here have > a lot of paranoia. Signing packages on the master mirror guards against compromised or spoofed mirrors. Not trusting the master mirror or its admins is a separate, and much harder problem. -- Colin Phippshttp://www.netcraft.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-21 Peter Cordes wrote: > On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > > On 00-12-21 Dan Hutchinson wrote: > > > Sorry it was fornesics, but the code is basically matching the machine > > > code, a unique pattern of 1's and 0's to the machine code of the kernal. > > > > Well, but then you need to know all patterns of malicous code that could > > occur. I think this will be a lot of patterns that you have to search > > for, so that the search will take a long time. > > > > > Unless you have a kernal file that doesn't have 1's and 0's in machine > > > language, you can scan the code. I am not sure how ASM code is written > > > thou. > > > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > > machine-code that is used by the processor. I thaught you wanted to scan > > the code that you find beneath /usr/src/linux. > You have to search the binary kernel image. If you just scan the source, > you have no way of knowing that the binary came from the source. Someone > could hack the binary without changing the source. If there are any > commonly-made changes to the binary, then you could look for them. Agreed, but then you have to scan the modules as well, as someone could change a module too or add one. > It will be hard to do, and impossible to do perfectly. The Right Way is to > keep a hash of your kernel binary so you know if it changes. BTW, md5 has > not been broken, AFAIK, so there is no currently known way to change a > binary without changing its MD5 hash, except trial and error, which would > take a lot more _years_ than anyone would want to wait! You expressed doubt > about this earlier. Rest assured that no real breaks in MD5 have been made > public. (The NSA might have something, but they don't publish.) The md5sum > manpage notes: >The related MD4 message digest algorithm was broken in >October 1995. MD5 isn't looking as secure as it used to. I just looked again in the Schneier to reread the paragraph about MD5. And if you use the compression function in MD5, you can produce collions like den Boer and Boesselaer proofed it. So, you should be careful about the usage of MD5 as Digest Algorithmen, because a "basic design principles [of MD5] - to design a collision-resistant function - has been violated". So I would be very careful about the usage of this algorithmen. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian audititing tool?
On 00-12-21 Colin Phipps wrote: > On Thu, Dec 21, 2000 at 04:09:07PM +0100, Christian Kurz wrote: > > [ Would you please stop those Ccs to me?] > If you don't want CC's then fix your mail headers: > Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, > debian-security@lists.debian.org They are, as they contain: |Mail-Copies-To: never which means that I don't want a Mail Copy of an answer. > > On 00-12-21 Colin Phipps wrote: > > > > No, I tried to explain why it also won't work for the > > > > "less-careful" intruders, as they will use tools to hide their > > > > changes. > > > > > Some intruders will be careless or ignorant and it'll catch them. > > > Others will be smart and it won't. Assuming at least some hackers > > > are careless it's still worthwhile, in the absence of a perfect > > > solution. > > > > Well and the one that you won't catch to much more damage to your > > system and create a higher risk then the one you catch. > Agreed, if someone gets root on your system there's no way you can > guarantee detecting it. But you can try. Whether md5sums is worthwhile > I don't know, I guess you'd have to look for some statistics on > rootkits and such... Yes, such a statistic would be helpful as I think that only a small part of the rootkits are really know and every other rootkit is not know and only available in the underground. > > > No, you just sign all the packages on master.debian.org with this > > > official key, and then mirror both the files and their signatures > > > (as kernel.org do). > > > > And who will create this key? Who will have the passphrase? Who will > > sign the packages? > Someone on master.debian.org, presumably the ftp admins. And so you trust this admins? Just asking because some people here have a lot of paranoia. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp5OiN0HHYk5.pgp Description: PGP signature
Re: Debian audititing tool?
You are correct in that the binary would have to be scanned as well, but I was thinking of recompiling the binary from the scanned source. As to doing the search to find possible "signatures" that virus have, since many virus are deviation of an original virus you can use pattern matching from an original back orifice trojan to catch back orifice 2000. To get a list or code of these virus, www.antionline.org, www.mcafee.com, and other virus scan sites will give you lists and even a very complete display of the known familiar virus, trojens on the internet. It is a good start. Some thing several commerial companies are developing currently and would be a good project to start with GNU probably. Also with the Debian Firewall/Gibrator?(sorry for the spelling) does it include SNMP and remote managibility. Dan Peter Cordes <[EMAIL PROTECTED]> wrote: > On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > > On 00-12-21 Dan Hutchinson wrote: > > > Sorry it was fornesics, but the code is basically matching the > machine > > > code, a unique pattern of 1's and 0's to the machine code of the > kernal. > > > > Well, but then you need to know all patterns of malicous code that > could > > occur. I think this will be a lot of patterns that you have to search > > for, so that the search will take a long time. > > > > > Unless you have a kernal file that doesn't have 1's and 0's in > machine > > > language, you can scan the code. I am not sure how ASM code is > written > > > thou. > > > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > > machine-code that is used by the processor. I thaught you wanted > to scan > > the code that you find beneath /usr/src/linux. > > You have to search the binary kernel image. If you just scan the > source, > you have no way of knowing that the binary came from the source. Someone > could hack the binary without changing the source. If there are any > commonly-made changes to the binary, then you could look for them. > > It will be hard to do, and impossible to do perfectly. The Right > Way is to > keep a hash of your kernel binary so you know if it changes. BTW, > md5 has > not been broken, AFAIK, so there is no currently known way to change > a > binary without changing its MD5 hash, except trial and error, which > would > take a lot more _years_ than anyone would want to wait! You expressed > doubt > about this earlier. Rest assured that no real breaks in MD5 have been > made > public. (The NSA might have something, but they don't publish.) The > md5sum > manpage notes: >The related MD4 message digest algorithm was broken in >October 1995. MD5 isn't looking as secure as it used to. > > I think a signed database of stuff that's supposed to be in Debian, > and a > decent way to make a bootable CD that downloads what it needs, and > checks > what's on your drive, is a good start. If the MD5 sum lists are signed, > you > don't need to trust the server you download them from. > > -- > #define X(x,y) x##y > Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) > > "The gods confound the man who first found out how to distinguish the > hours! > Confound him, too, who in this place set up a sundial, to cut and > hack > my day so wretchedly into small pieces!" -- Plautus, 200 BCE > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:48:40PM -0500, Jacob Kuntz wrote: > from the secret journal of Rene Mayrhofer ([EMAIL PROTECTED]): > > http://www.gibaltar.at/ > > is that address correct? i didn't think there was a .at tld, but there are > two 'r's in gibraltar. the correct URL is http://www.gibraltar.at/ (just checked and copy/pasted). -- -m When you are having a bad day, and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle.
Re: Debian audititing tool?
from the secret journal of Rene Mayrhofer ([EMAIL PROTECTED]): > http://www.gibaltar.at/ is that address correct? i didn't think there was a .at tld, but there are two 'r's in gibraltar. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] "Strategery" -- George W. Bush "Lockbox" -- Al Gore
Re: Debian audititing tool?
Peter Cordes wrote: > I think a signed database of stuff that's supposed to be in Debian, and a > decent way to make a bootable CD that downloads what it needs, and checks > what's on your drive, is a good start. If the MD5 sum lists are signed, you > don't need to trust the server you download them from. That's the reason why the Gibraltar firewall (Debian based) runs directly from a bootable CD-ROM. You only need to protect your configuration, but you don't need to worry about your binaries. http://www.gibaltar.at/ best greets, Rene
Re: Debian audititing tool?
On 00-12-21 Colin Phipps wrote: > On Thu, Dec 21, 2000 at 04:09:07PM +0100, Christian Kurz wrote: > > [ Would you please stop those Ccs to me?] > If you don't want CC's then fix your mail headers: > Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, >[EMAIL PROTECTED] They are, as they contain: |Mail-Copies-To: never which means that I don't want a Mail Copy of an answer. > > On 00-12-21 Colin Phipps wrote: > > > > No, I tried to explain why it also won't work for the > > > > "less-careful" intruders, as they will use tools to hide their > > > > changes. > > > > > Some intruders will be careless or ignorant and it'll catch them. > > > Others will be smart and it won't. Assuming at least some hackers > > > are careless it's still worthwhile, in the absence of a perfect > > > solution. > > > > Well and the one that you won't catch to much more damage to your > > system and create a higher risk then the one you catch. > Agreed, if someone gets root on your system there's no way you can > guarantee detecting it. But you can try. Whether md5sums is worthwhile > I don't know, I guess you'd have to look for some statistics on > rootkits and such... Yes, such a statistic would be helpful as I think that only a small part of the rootkits are really know and every other rootkit is not know and only available in the underground. > > > No, you just sign all the packages on master.debian.org with this > > > official key, and then mirror both the files and their signatures > > > (as kernel.org do). > > > > And who will create this key? Who will have the passphrase? Who will > > sign the packages? > Someone on master.debian.org, presumably the ftp admins. And so you trust this admins? Just asking because some people here have a lot of paranoia. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > On 00-12-21 Dan Hutchinson wrote: > > Sorry it was fornesics, but the code is basically matching the machine > > code, a unique pattern of 1's and 0's to the machine code of the kernal. > > Well, but then you need to know all patterns of malicous code that could > occur. I think this will be a lot of patterns that you have to search > for, so that the search will take a long time. > > > Unless you have a kernal file that doesn't have 1's and 0's in machine > > language, you can scan the code. I am not sure how ASM code is written > > thou. > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > machine-code that is used by the processor. I thaught you wanted to scan > the code that you find beneath /usr/src/linux. You have to search the binary kernel image. If you just scan the source, you have no way of knowing that the binary came from the source. Someone could hack the binary without changing the source. If there are any commonly-made changes to the binary, then you could look for them. It will be hard to do, and impossible to do perfectly. The Right Way is to keep a hash of your kernel binary so you know if it changes. BTW, md5 has not been broken, AFAIK, so there is no currently known way to change a binary without changing its MD5 hash, except trial and error, which would take a lot more _years_ than anyone would want to wait! You expressed doubt about this earlier. Rest assured that no real breaks in MD5 have been made public. (The NSA might have something, but they don't publish.) The md5sum manpage notes: The related MD4 message digest algorithm was broken in October 1995. MD5 isn't looking as secure as it used to. I think a signed database of stuff that's supposed to be in Debian, and a decent way to make a bootable CD that downloads what it needs, and checks what's on your drive, is a good start. If the MD5 sum lists are signed, you don't need to trust the server you download them from. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Debian audititing tool?
You are correct in that the binary would have to be scanned as well, but I was thinking of recompiling the binary from the scanned source. As to doing the search to find possible "signatures" that virus have, since many virus are deviation of an original virus you can use pattern matching from an original back orifice trojan to catch back orifice 2000. To get a list or code of these virus, www.antionline.org, www.mcafee.com, and other virus scan sites will give you lists and even a very complete display of the known familiar virus, trojens on the internet. It is a good start. Some thing several commerial companies are developing currently and would be a good project to start with GNU probably. Also with the Debian Firewall/Gibrator?(sorry for the spelling) does it include SNMP and remote managibility. Dan Peter Cordes <[EMAIL PROTECTED]> wrote: > On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > > On 00-12-21 Dan Hutchinson wrote: > > > Sorry it was fornesics, but the code is basically matching the > machine > > > code, a unique pattern of 1's and 0's to the machine code of the > kernal. > > > > Well, but then you need to know all patterns of malicous code that > could > > occur. I think this will be a lot of patterns that you have to search > > for, so that the search will take a long time. > > > > > Unless you have a kernal file that doesn't have 1's and 0's in > machine > > > language, you can scan the code. I am not sure how ASM code is > written > > > thou. > > > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > > machine-code that is used by the processor. I thaught you wanted > to scan > > the code that you find beneath /usr/src/linux. > > You have to search the binary kernel image. If you just scan the > source, > you have no way of knowing that the binary came from the source. Someone > could hack the binary without changing the source. If there are any > commonly-made changes to the binary, then you could look for them. > > It will be hard to do, and impossible to do perfectly. The Right > Way is to > keep a hash of your kernel binary so you know if it changes. BTW, > md5 has > not been broken, AFAIK, so there is no currently known way to change > a > binary without changing its MD5 hash, except trial and error, which > would > take a lot more _years_ than anyone would want to wait! You expressed > doubt > about this earlier. Rest assured that no real breaks in MD5 have been > made > public. (The NSA might have something, but they don't publish.) The > md5sum > manpage notes: >The related MD4 message digest algorithm was broken in >October 1995. MD5 isn't looking as secure as it used to. > > I think a signed database of stuff that's supposed to be in Debian, > and a > decent way to make a bootable CD that downloads what it needs, and > checks > what's on your drive, is a good start. If the MD5 sum lists are signed, > you > don't need to trust the server you download them from. > > -- > #define X(x,y) x##y > Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) > > "The gods confound the man who first found out how to distinguish the > hours! > Confound him, too, who in this place set up a sundial, to cut and > hack > my day so wretchedly into small pieces!" -- Plautus, 200 BCE > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:48:40PM -0500, Jacob Kuntz wrote: > from the secret journal of Rene Mayrhofer ([EMAIL PROTECTED]): > > http://www.gibaltar.at/ > > is that address correct? i didn't think there was a .at tld, but there are > two 'r's in gibraltar. the correct URL is http://www.gibraltar.at/ (just checked and copy/pasted). -- -m When you are having a bad day, and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
from the secret journal of Rene Mayrhofer ([EMAIL PROTECTED]): > http://www.gibaltar.at/ is that address correct? i didn't think there was a .at tld, but there are two 'r's in gibraltar. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] "Strategery" -- George W. Bush "Lockbox" -- Al Gore -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Peter Cordes wrote: > I think a signed database of stuff that's supposed to be in Debian, and a > decent way to make a bootable CD that downloads what it needs, and checks > what's on your drive, is a good start. If the MD5 sum lists are signed, you > don't need to trust the server you download them from. That's the reason why the Gibraltar firewall (Debian based) runs directly from a bootable CD-ROM. You only need to protect your configuration, but you don't need to worry about your binaries. http://www.gibaltar.at/ best greets, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > On 00-12-21 Dan Hutchinson wrote: > > Sorry it was fornesics, but the code is basically matching the machine > > code, a unique pattern of 1's and 0's to the machine code of the kernal. > > Well, but then you need to know all patterns of malicous code that could > occur. I think this will be a lot of patterns that you have to search > for, so that the search will take a long time. > > > Unless you have a kernal file that doesn't have 1's and 0's in machine > > language, you can scan the code. I am not sure how ASM code is written > > thou. > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > machine-code that is used by the processor. I thaught you wanted to scan > the code that you find beneath /usr/src/linux. You have to search the binary kernel image. If you just scan the source, you have no way of knowing that the binary came from the source. Someone could hack the binary without changing the source. If there are any commonly-made changes to the binary, then you could look for them. It will be hard to do, and impossible to do perfectly. The Right Way is to keep a hash of your kernel binary so you know if it changes. BTW, md5 has not been broken, AFAIK, so there is no currently known way to change a binary without changing its MD5 hash, except trial and error, which would take a lot more _years_ than anyone would want to wait! You expressed doubt about this earlier. Rest assured that no real breaks in MD5 have been made public. (The NSA might have something, but they don't publish.) The md5sum manpage notes: The related MD4 message digest algorithm was broken in October 1995. MD5 isn't looking as secure as it used to. I think a signed database of stuff that's supposed to be in Debian, and a decent way to make a bootable CD that downloads what it needs, and checks what's on your drive, is a good start. If the MD5 sum lists are signed, you don't need to trust the server you download them from. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Friday, 2000-12-22 at 00:11:38 +1100, Peter Eckersley wrote: > I understand the requirement for read-only media. Tripwire should give > me a "clean" snapshot of a system. But when I administer a machine, I > regularly make changes to the "clean" image. If I want tripwire to > track this, I must do the following every time I want to update the > system: > 1. Reboot with a clean kernel > 2. Run tripwire with my read-only record > 3. Install my Debian packages > 4. Update my read-only record Have a look at (Free)Veracity. While the license may hurt an Open Source or Free Software activist's feelings, the tool seems todo what (probably not only) I have been missing in Tripwire - remote checks. The database can reside on a different machine. Given that Veracity offers a number of checksumming algorithms, it would be quite hard to fool it. I can still imagine a scenario how to defeat this, but it's definitely better than running tripwire with a mutable database, or having a trained monkey write-enable the floppy when needed. (Ay my clients, monkeys are in short supply.) Commercial/non-free Veracity is at http://www.veracity.com/ and Free Veracity is at http://www.freeveracity.org/ Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | The equal opportunity democracy - every vote has an equal chance | | of being counted. Though a bad one if you live in Florida. | | Those people told us how to run a democracy ?!?|
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:22:10PM +, Colin Phipps wrote: > > Well and the one that you won't catch to much more damage to your system > > and create a higher risk then the one you catch. > > Agreed, if someone gets root on your system there's no way you can > guarantee detecting it. But you can try. Whether md5sums is worthwhile > I don't know, I guess you'd have to look for some statistics on > rootkits and such... > Well, you certainly can't catch them with debsums. You can probably catch them with tripwire, if you're willing to spend lots of time and effort using it. I was motivated by the idea that Debian could do much better than tripwire - ie, the same security, with much less effort on the part of the administrator. -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgpArwQZlhkXD.pgp Description: PGP signature
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 04:09:07PM +0100, Christian Kurz wrote: > [ Would you please stop those Ccs to me?] If you don't want CC's then fix your mail headers: Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, debian-security@lists.debian.org > On 00-12-21 Colin Phipps wrote: > > > No, I tried to explain why it also won't work for the "less-careful" > > > intruders, as they will use tools to hide their changes. > > > Some intruders will be careless or ignorant and it'll catch them. Others > > will be smart and it won't. Assuming at least some hackers are careless > > it's > > still worthwhile, in the absence of a perfect solution. > > Well and the one that you won't catch to much more damage to your system > and create a higher risk then the one you catch. Agreed, if someone gets root on your system there's no way you can guarantee detecting it. But you can try. Whether md5sums is worthwhile I don't know, I guess you'd have to look for some statistics on rootkits and such... > > No, you just sign all the packages on master.debian.org with this official > > key, and then mirror both the files and their signatures (as kernel.org do). > > And who will create this key? Who will have the passphrase? Who will > sign the packages? Someone on master.debian.org, presumably the ftp admins. > How do you make sure that the signatures get's not corrupted? apt would refuse to install stuff where the signature check failed. -- Colin Phippshttp://www.netcraft.com/
Re: Debian audititing tool?
[ Would you please stop those Ccs to me?] On 00-12-21 Colin Phipps wrote: > On Thu, Dec 21, 2000 at 03:30:25PM +0100, Christian Kurz wrote: > > > > > Hence my comment. "Less-clueful" intruders won't modify > > > > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > > > > but will not help if the cracker is smart. > > > > > > > > No, as it would say that if this md5sums will be wide spread, someone > > > > will write a tool to modify binaries without modifying the md5sum and > > > > then you have the problem again... > This is not possible, that's the point of using md5sums in this case, it's > computationally infeasible to construct a different file with the same > md5sum. Sure, I haven't read the Schneier so far, but I'm not sure about this. > > > > ...or even create a tool that replaces the > > > > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one > Which is why you would have to get the list of md5sums from a trusted source. > > No, I tried to explain why it also won't work for the "less-careful" > > intruders, as they will use tools to hide their changes. > Some intruders will be careless or ignorant and it'll catch them. Others > will be smart and it won't. Assuming at least some hackers are careless it's > still worthwhile, in the absence of a perfect solution. Well and the one that you won't catch to much more damage to your system and create a higher risk then the one you catch. > > > if I were trying to do mirror authentication, I'd ship apt with an > > > official .debian.org public key, and then ask .debian.org whether a > > > the public key presented by a mirror was kosher. There are other ways > > > of doing it... > > > > puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key > > do you think of? Also this would impose that everyone downloads package > > from only one .debian.org server and this would generate a lot of > > traffic and resources on this machine. Or otherwise you have to convince > > every admin of .debian.org to generate a public key and install them all > > when you install apt. > No, you just sign all the packages on master.debian.org with this official > key, and then mirror both the files and their signatures (as kernel.org do). And who will create this key? Who will have the passphrase? Who will sign the packages? How do you make sure that the signatures get's not corrupted? Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > Well, but then you need to know all patterns of malicous code that could > occur. I think this will be a lot of patterns that you have to search > for, so that the search will take a long time. > > > Unless you have a kernal file that doesn't have 1's and 0's in machine > > language, you can scan the code. I am not sure how ASM code is written > > thou. > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > machine-code that is used by the processor. I thaught you wanted to scan > the code that you find beneath /usr/src/linux. > I meant search for machine-code patterns. Yes there are lots of them, but string searching is fast. This is exactly the same as M$ virus scanning. -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgp0IEFV9Qd0k.pgp Description: PGP signature
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:30:25PM +0100, Christian Kurz wrote: > > > > Hence my comment. "Less-clueful" intruders won't modify > > > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > > > but will not help if the cracker is smart. > > > > > > No, as it would say that if this md5sums will be wide spread, someone > > > will write a tool to modify binaries without modifying the md5sum and > > > then you have the problem again... This is not possible, that's the point of using md5sums in this case, it's computationally infeasible to construct a different file with the same md5sum. > > > ...or even create a tool that replaces the > > > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one Which is why you would have to get the list of md5sums from a trusted source. > No, I tried to explain why it also won't work for the "less-careful" > intruders, as they will use tools to hide their changes. Some intruders will be careless or ignorant and it'll catch them. Others will be smart and it won't. Assuming at least some hackers are careless it's still worthwhile, in the absence of a perfect solution. > > if I were trying to do mirror authentication, I'd ship apt with an > > official .debian.org public key, and then ask .debian.org whether a > > the public key presented by a mirror was kosher. There are other ways > > of doing it... > > puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key > do you think of? Also this would impose that everyone downloads package > from only one .debian.org server and this would generate a lot of > traffic and resources on this machine. Or otherwise you have to convince > every admin of .debian.org to generate a public key and install them all > when you install apt. No, you just sign all the packages on master.debian.org with this official key, and then mirror both the files and their signatures (as kernel.org do). -- Colin Phippshttp://www.netcraft.com/
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:30:25PM +0100, Christian Kurz wrote: > > if I were trying to do mirror authentication, I'd ship apt with an > > official .debian.org public key, and then ask .debian.org whether a > > the public key presented by a mirror was kosher. There are other ways > > of doing it... > > puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key > do you think of? Well I actually meant "public key" in the theoretical sense, rather than specifying an implementation. I imagine you could use a scheme similar to the one SSH uses for host verification. > And what about rootkits that are often used and not widespread but that > you don't detect really? I think that also such a rootkit is already > existing. I said it wasn't perfect. Detection of some rootkits is better than none. I also don't understand what you mean by "often used and not widespread". > > > * automatic recognition of changes to the snapshot which correspond to > > the installation of packages from /etc/apt/sources.list, possibly > > augmented by mirror authentication > > You still failed to describe how you want to do automatic recognition of > packages. > Well, it seems to me that there are lots of ways of doing this with security which is at least as good as that of existing systems. They vary in elegance, required changes to Debian's infrastructure, and network utilisation. When I say security is "at least as good as that of existing systems", I mean that even if you can't detect intrusions from /etc/apt/sources.list, you *can* detect other intrusions. By the way, I just noticed that in this message, http://lists.debian.org/debian-devel-announce-0012/msg00012.html, ajt says that package signatures are "under development". My proposal is less than "under development" :) -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgpyaJ5KmGGXP.pgp Description: PGP signature
Re: Debian audititing tool?
On 00-12-21 Dan Hutchinson wrote: > Sorry it was fornesics, but the code is basically matching the machine > code, a unique pattern of 1's and 0's to the machine code of the kernal. Well, but then you need to know all patterns of malicous code that could occur. I think this will be a lot of patterns that you have to search for, so that the search will take a long time. > Unless you have a kernal file that doesn't have 1's and 0's in machine > language, you can scan the code. I am not sure how ASM code is written > thou. Well, ASM (assembler) comes also down to 1 and 0 if you think about machine-code that is used by the processor. I thaught you wanted to scan the code that you find beneath /usr/src/linux. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
Sorry I miss read your response. Well you can get the source kernel and run it threw the fornesics program then compile it possible. Anyway it will help with open trojans and virus anyway. Dan "Dan Hutchinson" <[EMAIL PROTECTED]> wrote: > Sorry it was fornesics, but the code is basically matching the machine > code, a unique pattern of 1's and 0's to the machine code of the kernal. > Unless you have a kernal file that doesn't have 1's and 0's in machine > language, you can scan the code. I am not sure how ASM code is written > thou. > > Dan > > Christian Kurz <[EMAIL PROTECTED]> wrote: > > On 00-12-21 Dan Hutchinson wrote: > > > I would agree with your comments except the scan of the Linux Kernel. > > > > Thanks. :) > > > > > You can use computer fornesics to scan the kernal against familiar > > trojan > > > and virus patterns realitively quickly and at least identify problem > > > > Hm, you know that some parts are written in ASM and that you could > > also > > use ASM in some parts of the kernel to protect malicous code? How > could > > a fornesics (Hm, do you mean forensic?) detect this asm-code and > know > > that it is malicous? > > > > Ciao > > Christian > > -- > > Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser > > und größer als ein "Ja" um zu gefallen oder noch schlimmer, um > > Schwierigkeiten zu umgehen. > > -- Mahatma Gandhi > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > ___ > To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, > all in one place - sign up today at http://www.zdnetonebox.com > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com
Re: Debian audititing tool?
Sorry it was fornesics, but the code is basically matching the machine code, a unique pattern of 1's and 0's to the machine code of the kernal. Unless you have a kernal file that doesn't have 1's and 0's in machine language, you can scan the code. I am not sure how ASM code is written thou. Dan Christian Kurz <[EMAIL PROTECTED]> wrote: > On 00-12-21 Dan Hutchinson wrote: > > I would agree with your comments except the scan of the Linux Kernel. > > Thanks. :) > > > You can use computer fornesics to scan the kernal against familiar > trojan > > and virus patterns realitively quickly and at least identify problem > > Hm, you know that some parts are written in ASM and that you could > also > use ASM in some parts of the kernel to protect malicous code? How could > a fornesics (Hm, do you mean forensic?) detect this asm-code and know > that it is malicous? > > Ciao > Christian > -- > Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser > und größer als ein "Ja" um zu gefallen oder noch schlimmer, um > Schwierigkeiten zu umgehen. > -- Mahatma Gandhi > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com
Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote: > On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote: > > > My suggested alternative is a system which knows about official Debian > > > packages, and will register that change as simply "installed/upgraded > > > package XYZ". > > > > Where should it register that? What exactly should it register? Your > > current description sounds like a system that just notes that package > > foo has been instaleld and nothing else. This will still make it > > possible to replace foo with an modified foo that allows someone to take > > your machine over. > If you are willing to trust your Debian mirror (or perhaps you could > even circumvent the mirror and go to .debian.org for signed checksums), Where do you have a signed checksum on .debian.org? > the audit tool will tell you "replaced foo with upgraded (official) foo > version#", or "ALERT: foo does not match official checksums". And how does it detect if the upgrade packageof official? Also the second detection will be based on the assumption that the file containing the checksum has not been replaced also. > > > Hence my comment. "Less-clueful" intruders won't modify > > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > > but will not help if the cracker is smart. > > > > No, as it would say that if this md5sums will be wide spread, someone > > will write a tool to modify binaries without modifying the md5sum and > > then you have the problem again or even create a tool that replaces the > > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so > > that debsum won't notice the difference. > I think we're agreeing with each other. I said "debsums is inadequate", > you appear to be trying to explain this to me. No, I tried to explain why it also won't work for the "less-careful" intruders, as they will use tools to hide their changes. > > > Of course, at some point, you have to make a leap of faith. ATM, most > > > Debian users trust their DNS server and their Debian mirror. IIRC, > > > Connectiva's modifications to apt-get will fix the "trust your DNS" > > > problem. > > > > Well, but you still have to trust your mirror and their admins? So how > > do you want to make sure that you can trust this mirror? Which > > modifications of apt are you talking about? What exactly did they > > modify? Did they change apt to not accept hostnames but only ip-address? > http://freshmeat.net/news/2000/12/02/975819599.html > Search for "mirror authentication". I'm not sure how they did it, but Well, no documentation about this available on the URL. > if I were trying to do mirror authentication, I'd ship apt with an > official .debian.org public key, and then ask .debian.org whether a > the public key presented by a mirror was kosher. There are other ways > of doing it... puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key do you think of? Also this would impose that everyone downloads package from only one .debian.org server and this would generate a lot of traffic and resources on this machine. Or otherwise you have to convince every admin of .debian.org to generate a public key and install them all when you install apt. > > What do you define as "vanilla"? Also remeber that rootkits can change > > and become more sophisticated in the future. And so you will also be in > > a time lag behind the people having the rootkits as you first have to > > get a copy of it to create a detection for it. > > > > > As new rootkits are observed "in the wild" (and a tool like this might > > > help find them :), they can be added to the list of trojan signatures. > > > This is closely analogous to the operation of virus scanners in M$ land. > > > > So you really think that someone who will write such a tool will be able > > to get acccess to all rootkits? I hope this is not meant serious. > I'm not claiming to have a solution for automatic rootkit detection. As > I said in the original email, kernel (and module) scanning is just an > extra feature which is not perfect, but which might help somebody one > day. Of course, there will always be new or mutating rootkits (like > there are new or mutating virii on Windows), but if any rootkit is in > widespread use, it will be detectable. And what about rootkits that are often used and not widespread but that you don't detect really? I think that also such a rootkit is already existing. > * automatic recognition of changes to the snapshot which correspond to > the installation of packages from /etc/apt/sources.list, possibly > augmented by mirror authentication You still failed to describe how you want to do automatic recognition of packages. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote: > > 1. Reboot with a clean kernel > > 2. Run tripwire with my read-only record > > 3. Install my Debian packages > > 4. Update my read-only record > > And you are running the system with an unclean kernel? If you not add > your kernel that you are running to the tripwire check, you won't notice > if anyone puts a bad module or a modified kernel on your system. Sorry, I wasn't clear enough. "Reboot with a clean kernel" should be "boot a clean system" - ie, a boot floppy or CD-ROM with a kernel *and* a filesystem. > > > My suggested alternative is a system which knows about official Debian > > packages, and will register that change as simply "installed/upgraded > > package XYZ". > > Where should it register that? What exactly should it register? Your > current description sounds like a system that just notes that package > foo has been instaleld and nothing else. This will still make it > possible to replace foo with an modified foo that allows someone to take > your machine over. If you are willing to trust your Debian mirror (or perhaps you could even circumvent the mirror and go to .debian.org for signed checksums), the audit tool will tell you "replaced foo with upgraded (official) foo version#", or "ALERT: foo does not match official checksums". You could produce output like this with a read-only archive or a security server, or you could just print a list of installed official packages. Not perfect, but much easier than using tripwire *and* no less secure (since you always have to trust your source of .debs). > > Hence my comment. "Less-clueful" intruders won't modify > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > but will not help if the cracker is smart. > > No, as it would say that if this md5sums will be wide spread, someone > will write a tool to modify binaries without modifying the md5sum and > then you have the problem again or even create a tool that replaces the > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so > that debsum won't notice the difference. I think we're agreeing with each other. I said "debsums is inadequate", you appear to be trying to explain this to me. > > Of course, at some point, you have to make a leap of faith. ATM, most > > Debian users trust their DNS server and their Debian mirror. IIRC, > > Connectiva's modifications to apt-get will fix the "trust your DNS" > > problem. > > Well, but you still have to trust your mirror and their admins? So how > do you want to make sure that you can trust this mirror? Which > modifications of apt are you talking about? What exactly did they > modify? Did they change apt to not accept hostnames but only ip-address? http://freshmeat.net/news/2000/12/02/975819599.html Search for "mirror authentication". I'm not sure how they did it, but if I were trying to do mirror authentication, I'd ship apt with an official .debian.org public key, and then ask .debian.org whether a the public key presented by a mirror was kosher. There are other ways of doing it... This is better than using IP addresses, because someone could maliciously re-route your traffic. Also, it might tip you off that someone was poisoning your DNS server... > > > A kernel source is "clean" when it has the Debian kernel maintainer's > > signature on it. A kernel binary is clean when the administrator: > > Which signature? If you download a debian package there's no signature > on it that you could check. So how do you want to check a signature and > make sure that there's no poisoned kernel-source on your debian mirror? > > > * gets a clean kernel source > > * compiles it, and records the md5sum of the kernel with the "security > > server" (or on a piece of paper). > > Of the kernel? What do you mean with kernel? Only vmlinuz? Or also the > modules? Be more precise. Okay, perhaps I was again insufficiently precise. The kernel needs to be treated specially, because it is frequently compiled from source (and is also obviously very security-sensitive). The modules are conceptually part of the kernel. Under my proposed scheme, you still need to treat the kernel in the same way that you treat everything with tripwire. > What do you define as "vanilla"? Also remeber that rootkits can change > and become more sophisticated in the future. And so you will also be in > a time lag behind the people having the rootkits as you first have to > get a copy of it to create a detection for it. > > > As new rootkits are observed "in the wild" (and a tool like this might > > help find them :), they can be added to the list of trojan signatures. > > This is closely analogous to the operation of virus scanners in M$ land. > > So you really think that someone who will write such a tool will be able > to get acccess to all rootkits? I hope this is not meant serious. > I'm not claiming to have a solution for automatic rootkit dete
Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote: > On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote: > > On 00-12-21 Peter Eckersley wrote: > > > Basically, I started reading the tripwire documentation, stopped, and > > > thought "Debian ought to make this *much* simpler". It seemed that if I > > > wanted to use tripwire, I'd need to tell it every time I was installing > > > a new package. I'd then need to update a record on read-only media... > > > > Hm, looking at your statement above, I get the feeling that you have no > > idea, what the purpose of tripwire really is. If you use it without a > > read-only media to save the data too and rerunning it when you install > > software on the machine, it won't be very helpful to track an intrusion. > I understand the requirement for read-only media. Tripwire should give > me a "clean" snapshot of a system. But when I administer a machine, I > regularly make changes to the "clean" image. If I want tripwire to > track this, I must do the following every time I want to update the > system: > 1. Reboot with a clean kernel > 2. Run tripwire with my read-only record > 3. Install my Debian packages > 4. Update my read-only record And you are running the system with an unclean kernel? If you not add your kernel that you are running to the tripwire check, you won't notice if anyone puts a bad module or a modified kernel on your system. > My suggested alternative is a system which knows about official Debian > packages, and will register that change as simply "installed/upgraded > package XYZ". Where should it register that? What exactly should it register? Your current description sounds like a system that just notes that package foo has been instaleld and nothing else. This will still make it possible to replace foo with an modified foo that allows someone to take your machine over. > > > Debsums seems to help a little bit - you can expect to catch some > > > less-clueful intruders with it, but it doesn't help in general. > > > > debsums just uses md5sums which can be manipulated on the one hand and > > on the other hand you modify binaries so that the md5sum will still be > > the same. > Hence my comment. "Less-clueful" intruders won't modify > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > but will not help if the cracker is smart. No, as it would say that if this md5sums will be wide spread, someone will write a tool to modify binaries without modifying the md5sum and then you have the problem again or even create a tool that replaces the md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so that debsum won't notice the difference. > > > What I'd really like is this: > > > > > A CDROM or boot floppy with a clean kernel, which downloads a set of clean > > > md5sums from a trusted server, and checks those. It could then produce a > > > list > > > of modified configuration files, which one would need to check by hand. > > > > So, how do you define clean kernel? Which kernel is really clean? How do > > you define if a server is trustable and how do you make sure that no one > > has put modified binaries on it? > Of course, at some point, you have to make a leap of faith. ATM, most > Debian users trust their DNS server and their Debian mirror. IIRC, > Connectiva's modifications to apt-get will fix the "trust your DNS" > problem. Well, but you still have to trust your mirror and their admins? So how do you want to make sure that you can trust this mirror? Which modifications of apt are you talking about? What exactly did they modify? Did they change apt to not accept hostnames but only ip-address? > A kernel source is "clean" when it has the Debian kernel maintainer's > signature on it. A kernel binary is clean when the administrator: Which signature? If you download a debian package there's no signature on it that you could check. So how do you want to check a signature and make sure that there's no poisoned kernel-source on your debian mirror? > * gets a clean kernel source > * compiles it, and records the md5sum of the kernel with the "security > server" (or on a piece of paper). Of the kernel? What do you mean with kernel? Only vmlinuz? Or also the modules? Be more precise. > > > * Kernel "trojan scans" for all known nasty kernel code. > > > > How do you want to do this with a source that is about 117M big? You > > have any idea how long it will take? Also you could hide nasty code very > > good in it and which will be hard to catch (This is an assumption by > > myself, after having looked at some parts of the kernel-source.) > This service is not perfect, that needs to be made clear. However, it > is reasonable to state that a large fraction of break-ins will use a > "vanilla" rootkit, which might be detected even if the administrator > *hasn't* recorded the custom kernel's checksum. What do you define as "vanilla"? Also remeber that rootkits can change and become more sophisticate
Re: Debian audititing tool?
On Friday, 2000-12-22 at 00:11:38 +1100, Peter Eckersley wrote: > I understand the requirement for read-only media. Tripwire should give > me a "clean" snapshot of a system. But when I administer a machine, I > regularly make changes to the "clean" image. If I want tripwire to > track this, I must do the following every time I want to update the > system: > 1. Reboot with a clean kernel > 2. Run tripwire with my read-only record > 3. Install my Debian packages > 4. Update my read-only record Have a look at (Free)Veracity. While the license may hurt an Open Source or Free Software activist's feelings, the tool seems todo what (probably not only) I have been missing in Tripwire - remote checks. The database can reside on a different machine. Given that Veracity offers a number of checksumming algorithms, it would be quite hard to fool it. I can still imagine a scenario how to defeat this, but it's definitely better than running tripwire with a mutable database, or having a trained monkey write-enable the floppy when needed. (Ay my clients, monkeys are in short supply.) Commercial/non-free Veracity is at http://www.veracity.com/ and Free Veracity is at http://www.freeveracity.org/ Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | The equal opportunity democracy - every vote has an equal chance | | of being counted. Though a bad one if you live in Florida. | | Those people told us how to run a democracy ?!?| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:22:10PM +, Colin Phipps wrote: > > Well and the one that you won't catch to much more damage to your system > > and create a higher risk then the one you catch. > > Agreed, if someone gets root on your system there's no way you can > guarantee detecting it. But you can try. Whether md5sums is worthwhile > I don't know, I guess you'd have to look for some statistics on > rootkits and such... > Well, you certainly can't catch them with debsums. You can probably catch them with tripwire, if you're willing to spend lots of time and effort using it. I was motivated by the idea that Debian could do much better than tripwire - ie, the same security, with much less effort on the part of the administrator. -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ PGP signature
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote: > On 00-12-21 Peter Eckersley wrote: > > Basically, I started reading the tripwire documentation, stopped, and > > thought "Debian ought to make this *much* simpler". It seemed that if I > > wanted to use tripwire, I'd need to tell it every time I was installing > > a new package. I'd then need to update a record on read-only media... > > Hm, looking at your statement above, I get the feeling that you have no > idea, what the purpose of tripwire really is. If you use it without a > read-only media to save the data too and rerunning it when you install > software on the machine, it won't be very helpful to track an intrusion. I understand the requirement for read-only media. Tripwire should give me a "clean" snapshot of a system. But when I administer a machine, I regularly make changes to the "clean" image. If I want tripwire to track this, I must do the following every time I want to update the system: 1. Reboot with a clean kernel 2. Run tripwire with my read-only record 3. Install my Debian packages 4. Update my read-only record My suggested alternative is a system which knows about official Debian packages, and will register that change as simply "installed/upgraded package XYZ". > > > Debsums seems to help a little bit - you can expect to catch some > > less-clueful intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand and > on the other hand you modify binaries so that the md5sum will still be > the same. Hence my comment. "Less-clueful" intruders won't modify /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, but will not help if the cracker is smart. > > > What I'd really like is this: > > > A CDROM or boot floppy with a clean kernel, which downloads a set of clean > > md5sums from a trusted server, and checks those. It could then produce a > > list > > of modified configuration files, which one would need to check by hand. > > So, how do you define clean kernel? Which kernel is really clean? How do > you define if a server is trustable and how do you make sure that no one > has put modified binaries on it? Of course, at some point, you have to make a leap of faith. ATM, most Debian users trust their DNS server and their Debian mirror. IIRC, Connectiva's modifications to apt-get will fix the "trust your DNS" problem. A kernel source is "clean" when it has the Debian kernel maintainer's signature on it. A kernel binary is clean when the administrator: * reboots the machine and uses the hypothetical auditing tool * gets a clean kernel source * compiles it, and records the md5sum of the kernel with the "security server" (or on a piece of paper). > > > * Kernel "trojan scans" for all known nasty kernel code. > > How do you want to do this with a source that is about 117M big? You > have any idea how long it will take? Also you could hide nasty code very > good in it and which will be hard to catch (This is an assumption by > myself, after having looked at some parts of the kernel-source.) This service is not perfect, that needs to be made clear. However, it is reasonable to state that a large fraction of break-ins will use a "vanilla" rootkit, which might be detected even if the administrator *hasn't* recorded the custom kernel's checksum. As new rootkits are observed "in the wild" (and a tool like this might help find them :), they can be added to the list of trojan signatures. This is closely analogous to the operation of virus scanners in M$ land. > > > * Debian security servers - these could keep a record of which config file > > changes you've okayed. They might also allow you to checksum customised > > What? Mirrors worldwide for your config-files? Use tripwire and you > don't need this. > > > * Heuristic analysis scripts to look for funny things in users' home > > directories, such as SETUID stuff and questionable aliases in .bashrc, for > > example (although this can never be perfect). > > You want to scan user-dirs without telling them that you do this? In > Germany you would better be careful with that as otherwise you could go > into jail for doing this. Please think about respecting the privacy of > your users. Do Windows sysadmins run their virus scanners with an "ignore users' files" flag? Have you added /home to your /etc/updatedb PRUNEPATHS? I am proposing the creation of a tool. Like any other tool, it might be abusable (not nearly as abusable as nmap, I might add). If using it in a particular way on a particular machine is inappropriate, then don't do it. > > > Does a tool like this exist already? If not, what do people think of the > > idea? > > No and I think on the one hand you have bit to much paranoia (Do you > have two entrance doors, grilled windows. a complete list of everything > in your house/flat in a safe by a lawyer? If no, I would suggest that > you think abo
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 04:09:07PM +0100, Christian Kurz wrote: > [ Would you please stop those Ccs to me?] If you don't want CC's then fix your mail headers: Mail-Followup-To: Christian Kurz <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > On 00-12-21 Colin Phipps wrote: > > > No, I tried to explain why it also won't work for the "less-careful" > > > intruders, as they will use tools to hide their changes. > > > Some intruders will be careless or ignorant and it'll catch them. Others > > will be smart and it won't. Assuming at least some hackers are careless it's > > still worthwhile, in the absence of a perfect solution. > > Well and the one that you won't catch to much more damage to your system > and create a higher risk then the one you catch. Agreed, if someone gets root on your system there's no way you can guarantee detecting it. But you can try. Whether md5sums is worthwhile I don't know, I guess you'd have to look for some statistics on rootkits and such... > > No, you just sign all the packages on master.debian.org with this official > > key, and then mirror both the files and their signatures (as kernel.org do). > > And who will create this key? Who will have the passphrase? Who will > sign the packages? Someone on master.debian.org, presumably the ftp admins. > How do you make sure that the signatures get's not corrupted? apt would refuse to install stuff where the signature check failed. -- Colin Phippshttp://www.netcraft.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-21 Dan Hutchinson wrote: > I would agree with your comments except the scan of the Linux Kernel. Thanks. :) > You can use computer fornesics to scan the kernal against familiar trojan > and virus patterns realitively quickly and at least identify problem Hm, you know that some parts are written in ASM and that you could also use ASM in some parts of the kernel to protect malicous code? How could a fornesics (Hm, do you mean forensic?) detect this asm-code and know that it is malicous? Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
[ Would you please stop those Ccs to me?] On 00-12-21 Colin Phipps wrote: > On Thu, Dec 21, 2000 at 03:30:25PM +0100, Christian Kurz wrote: > > > > > Hence my comment. "Less-clueful" intruders won't modify > > > > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > > > > but will not help if the cracker is smart. > > > > > > > > No, as it would say that if this md5sums will be wide spread, someone > > > > will write a tool to modify binaries without modifying the md5sum and > > > > then you have the problem again... > This is not possible, that's the point of using md5sums in this case, it's > computationally infeasible to construct a different file with the same > md5sum. Sure, I haven't read the Schneier so far, but I'm not sure about this. > > > > ...or even create a tool that replaces the > > > > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one > Which is why you would have to get the list of md5sums from a trusted source. > > No, I tried to explain why it also won't work for the "less-careful" > > intruders, as they will use tools to hide their changes. > Some intruders will be careless or ignorant and it'll catch them. Others > will be smart and it won't. Assuming at least some hackers are careless it's > still worthwhile, in the absence of a perfect solution. Well and the one that you won't catch to much more damage to your system and create a higher risk then the one you catch. > > > if I were trying to do mirror authentication, I'd ship apt with an > > > official .debian.org public key, and then ask .debian.org whether a > > > the public key presented by a mirror was kosher. There are other ways > > > of doing it... > > > > puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key > > do you think of? Also this would impose that everyone downloads package > > from only one .debian.org server and this would generate a lot of > > traffic and resources on this machine. Or otherwise you have to convince > > every admin of .debian.org to generate a public key and install them all > > when you install apt. > No, you just sign all the packages on master.debian.org with this official > key, and then mirror both the files and their signatures (as kernel.org do). And who will create this key? Who will have the passphrase? Who will sign the packages? How do you make sure that the signatures get's not corrupted? Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: > Well, but then you need to know all patterns of malicous code that could > occur. I think this will be a lot of patterns that you have to search > for, so that the search will take a long time. > > > Unless you have a kernal file that doesn't have 1's and 0's in machine > > language, you can scan the code. I am not sure how ASM code is written > > thou. > > Well, ASM (assembler) comes also down to 1 and 0 if you think about > machine-code that is used by the processor. I thaught you wanted to scan > the code that you find beneath /usr/src/linux. > I meant search for machine-code patterns. Yes there are lots of them, but string searching is fast. This is exactly the same as M$ virus scanning. -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ PGP signature
Re: Debian audititing tool?
I would agree with your comments except the scan of the Linux Kernel. You can use computer fornesics to scan the kernal against familiar trojan and virus patterns realitively quickly and at least identify problem code. It would be up to you to review to see if it is good or bad code. The scans where something like 5 minutes for a 5GB drive. It is just scan the 1s and 0s. Dan Christian Kurz <[EMAIL PROTECTED]> wrote: > On 00-12-21 Peter Eckersley wrote: > > Basically, I started reading the tripwire documentation, stopped, > and > > thought "Debian ought to make this *much* simpler". It seemed that > if I > > wanted to use tripwire, I'd need to tell it every time I was installing > > a new package. I'd then need to update a record on read-only media... > > Hm, looking at your statement above, I get the feeling that you have > no > idea, what the purpose of tripwire really is. If you use it without > a > read-only media to save the data too and rerunning it when you install > software on the machine, it won't be very helpful to track an intrusion. > > > Debsums seems to help a little bit - you can expect to catch some > less-clueful > > intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand > and > on the other hand you modify binaries so that the md5sum will still > be > the same. > > > What I'd really like is this: > > > A CDROM or boot floppy with a clean kernel, which downloads a set > of clean > > md5sums from a trusted server, and checks those. It could then produce > a list > > of modified configuration files, which one would need to check by > hand. > > So, how do you define clean kernel? Which kernel is really clean? How > do > you define if a server is trustable and how do you make sure that no > one > has put modified binaries on it? > > > * Kernel "trojan scans" for all known nasty kernel code. > > How do you want to do this with a source that is about 117M big? You > have any idea how long it will take? Also you could hide nasty code > very > good in it and which will be hard to catch (This is an assumption by > myself, after having looked at some parts of the kernel-source.) > > > * Debian security servers - these could keep a record of which config > file > > changes you've okayed. They might also allow you to checksum > customised > > What? Mirrors worldwide for your config-files? Use tripwire and you > don't need this. > > > * Heuristic analysis scripts to look for funny things in users' home > > directories, such as SETUID stuff and questionable aliases in .bashrc, > for > > example (although this can never be perfect). > > You want to scan user-dirs without telling them that you do this? In > Germany you would better be careful with that as otherwise you could > go > into jail for doing this. Please think about respecting the privacy > of > your users. > > > Does a tool like this exist already? If not, what do people think > of the idea? > > No and I think on the one hand you have bit to much paranoia (Do you > have two entrance doors, grilled windows. a complete list of everything > in your house/flat in a safe by a lawyer? If no, I would suggest that > you think about your ideas again.) and on the other hand you seem to > have missed the idea behind tools like tripwire. > > Ciao > Christian > -- > Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser > und größer als ein "Ja" um zu gefallen oder noch schlimmer, um > Schwierigkeiten zu umgehen. > -- Mahatma Gandhi > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:30:25PM +0100, Christian Kurz wrote: > > > > Hence my comment. "Less-clueful" intruders won't modify > > > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > > > but will not help if the cracker is smart. > > > > > > No, as it would say that if this md5sums will be wide spread, someone > > > will write a tool to modify binaries without modifying the md5sum and > > > then you have the problem again... This is not possible, that's the point of using md5sums in this case, it's computationally infeasible to construct a different file with the same md5sum. > > > ...or even create a tool that replaces the > > > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one Which is why you would have to get the list of md5sums from a trusted source. > No, I tried to explain why it also won't work for the "less-careful" > intruders, as they will use tools to hide their changes. Some intruders will be careless or ignorant and it'll catch them. Others will be smart and it won't. Assuming at least some hackers are careless it's still worthwhile, in the absence of a perfect solution. > > if I were trying to do mirror authentication, I'd ship apt with an > > official .debian.org public key, and then ask .debian.org whether a > > the public key presented by a mirror was kosher. There are other ways > > of doing it... > > puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key > do you think of? Also this would impose that everyone downloads package > from only one .debian.org server and this would generate a lot of > traffic and resources on this machine. Or otherwise you have to convince > every admin of .debian.org to generate a public key and install them all > when you install apt. No, you just sign all the packages on master.debian.org with this official key, and then mirror both the files and their signatures (as kernel.org do). -- Colin Phippshttp://www.netcraft.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 03:30:25PM +0100, Christian Kurz wrote: > > if I were trying to do mirror authentication, I'd ship apt with an > > official .debian.org public key, and then ask .debian.org whether a > > the public key presented by a mirror was kosher. There are other ways > > of doing it... > > puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key > do you think of? Well I actually meant "public key" in the theoretical sense, rather than specifying an implementation. I imagine you could use a scheme similar to the one SSH uses for host verification. > And what about rootkits that are often used and not widespread but that > you don't detect really? I think that also such a rootkit is already > existing. I said it wasn't perfect. Detection of some rootkits is better than none. I also don't understand what you mean by "often used and not widespread". > > > * automatic recognition of changes to the snapshot which correspond to > > the installation of packages from /etc/apt/sources.list, possibly > > augmented by mirror authentication > > You still failed to describe how you want to do automatic recognition of > packages. > Well, it seems to me that there are lots of ways of doing this with security which is at least as good as that of existing systems. They vary in elegance, required changes to Debian's infrastructure, and network utilisation. When I say security is "at least as good as that of existing systems", I mean that even if you can't detect intrusions from /etc/apt/sources.list, you *can* detect other intrusions. By the way, I just noticed that in this message, http://lists.debian.org/debian-devel-announce-0012/msg00012.html, ajt says that package signatures are "under development". My proposal is less than "under development" :) -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ PGP signature
Re: Debian audititing tool?
On 00-12-21 Peter Eckersley wrote: > Basically, I started reading the tripwire documentation, stopped, and > thought "Debian ought to make this *much* simpler". It seemed that if I > wanted to use tripwire, I'd need to tell it every time I was installing > a new package. I'd then need to update a record on read-only media... Hm, looking at your statement above, I get the feeling that you have no idea, what the purpose of tripwire really is. If you use it without a read-only media to save the data too and rerunning it when you install software on the machine, it won't be very helpful to track an intrusion. > Debsums seems to help a little bit - you can expect to catch some less-clueful > intruders with it, but it doesn't help in general. debsums just uses md5sums which can be manipulated on the one hand and on the other hand you modify binaries so that the md5sum will still be the same. > What I'd really like is this: > A CDROM or boot floppy with a clean kernel, which downloads a set of clean > md5sums from a trusted server, and checks those. It could then produce a list > of modified configuration files, which one would need to check by hand. So, how do you define clean kernel? Which kernel is really clean? How do you define if a server is trustable and how do you make sure that no one has put modified binaries on it? > * Kernel "trojan scans" for all known nasty kernel code. How do you want to do this with a source that is about 117M big? You have any idea how long it will take? Also you could hide nasty code very good in it and which will be hard to catch (This is an assumption by myself, after having looked at some parts of the kernel-source.) > * Debian security servers - these could keep a record of which config file > changes you've okayed. They might also allow you to checksum customised What? Mirrors worldwide for your config-files? Use tripwire and you don't need this. > * Heuristic analysis scripts to look for funny things in users' home > directories, such as SETUID stuff and questionable aliases in .bashrc, for > example (although this can never be perfect). You want to scan user-dirs without telling them that you do this? In Germany you would better be careful with that as otherwise you could go into jail for doing this. Please think about respecting the privacy of your users. > Does a tool like this exist already? If not, what do people think of the > idea? No and I think on the one hand you have bit to much paranoia (Do you have two entrance doors, grilled windows. a complete list of everything in your house/flat in a safe by a lawyer? If no, I would suggest that you think about your ideas again.) and on the other hand you seem to have missed the idea behind tools like tripwire. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On 00-12-21 Dan Hutchinson wrote: > Sorry it was fornesics, but the code is basically matching the machine > code, a unique pattern of 1's and 0's to the machine code of the kernal. Well, but then you need to know all patterns of malicous code that could occur. I think this will be a lot of patterns that you have to search for, so that the search will take a long time. > Unless you have a kernal file that doesn't have 1's and 0's in machine > language, you can scan the code. I am not sure how ASM code is written > thou. Well, ASM (assembler) comes also down to 1 and 0 if you think about machine-code that is used by the processor. I thaught you wanted to scan the code that you find beneath /usr/src/linux. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Sorry I miss read your response. Well you can get the source kernel and run it threw the fornesics program then compile it possible. Anyway it will help with open trojans and virus anyway. Dan "Dan Hutchinson" <[EMAIL PROTECTED]> wrote: > Sorry it was fornesics, but the code is basically matching the machine > code, a unique pattern of 1's and 0's to the machine code of the kernal. > Unless you have a kernal file that doesn't have 1's and 0's in machine > language, you can scan the code. I am not sure how ASM code is written > thou. > > Dan > > Christian Kurz <[EMAIL PROTECTED]> wrote: > > On 00-12-21 Dan Hutchinson wrote: > > > I would agree with your comments except the scan of the Linux Kernel. > > > > Thanks. :) > > > > > You can use computer fornesics to scan the kernal against familiar > > trojan > > > and virus patterns realitively quickly and at least identify problem > > > > Hm, you know that some parts are written in ASM and that you could > > also > > use ASM in some parts of the kernel to protect malicous code? How > could > > a fornesics (Hm, do you mean forensic?) detect this asm-code and > know > > that it is malicous? > > > > Ciao > > Christian > > -- > > Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser > > und größer als ein "Ja" um zu gefallen oder noch schlimmer, um > > Schwierigkeiten zu umgehen. > > -- Mahatma Gandhi > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > ___ > To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, > all in one place - sign up today at http://www.zdnetonebox.com > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
Sorry it was fornesics, but the code is basically matching the machine code, a unique pattern of 1's and 0's to the machine code of the kernal. Unless you have a kernal file that doesn't have 1's and 0's in machine language, you can scan the code. I am not sure how ASM code is written thou. Dan Christian Kurz <[EMAIL PROTECTED]> wrote: > On 00-12-21 Dan Hutchinson wrote: > > I would agree with your comments except the scan of the Linux Kernel. > > Thanks. :) > > > You can use computer fornesics to scan the kernal against familiar > trojan > > and virus patterns realitively quickly and at least identify problem > > Hm, you know that some parts are written in ASM and that you could > also > use ASM in some parts of the kernel to protect malicous code? How could > a fornesics (Hm, do you mean forensic?) detect this asm-code and know > that it is malicous? > > Ciao > Christian > -- > Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser > und größer als ein "Ja" um zu gefallen oder noch schlimmer, um > Schwierigkeiten zu umgehen. > -- Mahatma Gandhi > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote: > On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote: > > > My suggested alternative is a system which knows about official Debian > > > packages, and will register that change as simply "installed/upgraded > > > package XYZ". > > > > Where should it register that? What exactly should it register? Your > > current description sounds like a system that just notes that package > > foo has been instaleld and nothing else. This will still make it > > possible to replace foo with an modified foo that allows someone to take > > your machine over. > If you are willing to trust your Debian mirror (or perhaps you could > even circumvent the mirror and go to .debian.org for signed checksums), Where do you have a signed checksum on .debian.org? > the audit tool will tell you "replaced foo with upgraded (official) foo > version#", or "ALERT: foo does not match official checksums". And how does it detect if the upgrade packageof official? Also the second detection will be based on the assumption that the file containing the checksum has not been replaced also. > > > Hence my comment. "Less-clueful" intruders won't modify > > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > > but will not help if the cracker is smart. > > > > No, as it would say that if this md5sums will be wide spread, someone > > will write a tool to modify binaries without modifying the md5sum and > > then you have the problem again or even create a tool that replaces the > > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so > > that debsum won't notice the difference. > I think we're agreeing with each other. I said "debsums is inadequate", > you appear to be trying to explain this to me. No, I tried to explain why it also won't work for the "less-careful" intruders, as they will use tools to hide their changes. > > > Of course, at some point, you have to make a leap of faith. ATM, most > > > Debian users trust their DNS server and their Debian mirror. IIRC, > > > Connectiva's modifications to apt-get will fix the "trust your DNS" > > > problem. > > > > Well, but you still have to trust your mirror and their admins? So how > > do you want to make sure that you can trust this mirror? Which > > modifications of apt are you talking about? What exactly did they > > modify? Did they change apt to not accept hostnames but only ip-address? > http://freshmeat.net/news/2000/12/02/975819599.html > Search for "mirror authentication". I'm not sure how they did it, but Well, no documentation about this available on the URL. > if I were trying to do mirror authentication, I'd ship apt with an > official .debian.org public key, and then ask .debian.org whether a > the public key presented by a mirror was kosher. There are other ways > of doing it... puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key do you think of? Also this would impose that everyone downloads package from only one .debian.org server and this would generate a lot of traffic and resources on this machine. Or otherwise you have to convince every admin of .debian.org to generate a public key and install them all when you install apt. > > What do you define as "vanilla"? Also remeber that rootkits can change > > and become more sophisticated in the future. And so you will also be in > > a time lag behind the people having the rootkits as you first have to > > get a copy of it to create a detection for it. > > > > > As new rootkits are observed "in the wild" (and a tool like this might > > > help find them :), they can be added to the list of trojan signatures. > > > This is closely analogous to the operation of virus scanners in M$ land. > > > > So you really think that someone who will write such a tool will be able > > to get acccess to all rootkits? I hope this is not meant serious. > I'm not claiming to have a solution for automatic rootkit detection. As > I said in the original email, kernel (and module) scanning is just an > extra feature which is not perfect, but which might help somebody one > day. Of course, there will always be new or mutating rootkits (like > there are new or mutating virii on Windows), but if any rootkit is in > widespread use, it will be detectable. And what about rootkits that are often used and not widespread but that you don't detect really? I think that also such a rootkit is already existing. > * automatic recognition of changes to the snapshot which correspond to > the installation of packages from /etc/apt/sources.list, possibly > augmented by mirror authentication You still failed to describe how you want to do automatic recognition of packages. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote: > > 1. Reboot with a clean kernel > > 2. Run tripwire with my read-only record > > 3. Install my Debian packages > > 4. Update my read-only record > > And you are running the system with an unclean kernel? If you not add > your kernel that you are running to the tripwire check, you won't notice > if anyone puts a bad module or a modified kernel on your system. Sorry, I wasn't clear enough. "Reboot with a clean kernel" should be "boot a clean system" - ie, a boot floppy or CD-ROM with a kernel *and* a filesystem. > > > My suggested alternative is a system which knows about official Debian > > packages, and will register that change as simply "installed/upgraded > > package XYZ". > > Where should it register that? What exactly should it register? Your > current description sounds like a system that just notes that package > foo has been instaleld and nothing else. This will still make it > possible to replace foo with an modified foo that allows someone to take > your machine over. If you are willing to trust your Debian mirror (or perhaps you could even circumvent the mirror and go to .debian.org for signed checksums), the audit tool will tell you "replaced foo with upgraded (official) foo version#", or "ALERT: foo does not match official checksums". You could produce output like this with a read-only archive or a security server, or you could just print a list of installed official packages. Not perfect, but much easier than using tripwire *and* no less secure (since you always have to trust your source of .debs). > > Hence my comment. "Less-clueful" intruders won't modify > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > but will not help if the cracker is smart. > > No, as it would say that if this md5sums will be wide spread, someone > will write a tool to modify binaries without modifying the md5sum and > then you have the problem again or even create a tool that replaces the > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so > that debsum won't notice the difference. I think we're agreeing with each other. I said "debsums is inadequate", you appear to be trying to explain this to me. > > Of course, at some point, you have to make a leap of faith. ATM, most > > Debian users trust their DNS server and their Debian mirror. IIRC, > > Connectiva's modifications to apt-get will fix the "trust your DNS" > > problem. > > Well, but you still have to trust your mirror and their admins? So how > do you want to make sure that you can trust this mirror? Which > modifications of apt are you talking about? What exactly did they > modify? Did they change apt to not accept hostnames but only ip-address? http://freshmeat.net/news/2000/12/02/975819599.html Search for "mirror authentication". I'm not sure how they did it, but if I were trying to do mirror authentication, I'd ship apt with an official .debian.org public key, and then ask .debian.org whether a the public key presented by a mirror was kosher. There are other ways of doing it... This is better than using IP addresses, because someone could maliciously re-route your traffic. Also, it might tip you off that someone was poisoning your DNS server... > > > A kernel source is "clean" when it has the Debian kernel maintainer's > > signature on it. A kernel binary is clean when the administrator: > > Which signature? If you download a debian package there's no signature > on it that you could check. So how do you want to check a signature and > make sure that there's no poisoned kernel-source on your debian mirror? > > > * gets a clean kernel source > > * compiles it, and records the md5sum of the kernel with the "security > > server" (or on a piece of paper). > > Of the kernel? What do you mean with kernel? Only vmlinuz? Or also the > modules? Be more precise. Okay, perhaps I was again insufficiently precise. The kernel needs to be treated specially, because it is frequently compiled from source (and is also obviously very security-sensitive). The modules are conceptually part of the kernel. Under my proposed scheme, you still need to treat the kernel in the same way that you treat everything with tripwire. > What do you define as "vanilla"? Also remeber that rootkits can change > and become more sophisticated in the future. And so you will also be in > a time lag behind the people having the rootkits as you first have to > get a copy of it to create a detection for it. > > > As new rootkits are observed "in the wild" (and a tool like this might > > help find them :), they can be added to the list of trojan signatures. > > This is closely analogous to the operation of virus scanners in M$ land. > > So you really think that someone who will write such a tool will be able > to get acccess to all rootkits? I hope this is not meant serious. > I'm not claiming to have a solution for automatic rootkit det
Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote: > On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote: > > On 00-12-21 Peter Eckersley wrote: > > > Basically, I started reading the tripwire documentation, stopped, and > > > thought "Debian ought to make this *much* simpler". It seemed that if I > > > wanted to use tripwire, I'd need to tell it every time I was installing > > > a new package. I'd then need to update a record on read-only media... > > > > Hm, looking at your statement above, I get the feeling that you have no > > idea, what the purpose of tripwire really is. If you use it without a > > read-only media to save the data too and rerunning it when you install > > software on the machine, it won't be very helpful to track an intrusion. > I understand the requirement for read-only media. Tripwire should give > me a "clean" snapshot of a system. But when I administer a machine, I > regularly make changes to the "clean" image. If I want tripwire to > track this, I must do the following every time I want to update the > system: > 1. Reboot with a clean kernel > 2. Run tripwire with my read-only record > 3. Install my Debian packages > 4. Update my read-only record And you are running the system with an unclean kernel? If you not add your kernel that you are running to the tripwire check, you won't notice if anyone puts a bad module or a modified kernel on your system. > My suggested alternative is a system which knows about official Debian > packages, and will register that change as simply "installed/upgraded > package XYZ". Where should it register that? What exactly should it register? Your current description sounds like a system that just notes that package foo has been instaleld and nothing else. This will still make it possible to replace foo with an modified foo that allows someone to take your machine over. > > > Debsums seems to help a little bit - you can expect to catch some > > > less-clueful intruders with it, but it doesn't help in general. > > > > debsums just uses md5sums which can be manipulated on the one hand and > > on the other hand you modify binaries so that the md5sum will still be > > the same. > Hence my comment. "Less-clueful" intruders won't modify > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > but will not help if the cracker is smart. No, as it would say that if this md5sums will be wide spread, someone will write a tool to modify binaries without modifying the md5sum and then you have the problem again or even create a tool that replaces the md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so that debsum won't notice the difference. > > > What I'd really like is this: > > > > > A CDROM or boot floppy with a clean kernel, which downloads a set of clean > > > md5sums from a trusted server, and checks those. It could then produce a list > > > of modified configuration files, which one would need to check by hand. > > > > So, how do you define clean kernel? Which kernel is really clean? How do > > you define if a server is trustable and how do you make sure that no one > > has put modified binaries on it? > Of course, at some point, you have to make a leap of faith. ATM, most > Debian users trust their DNS server and their Debian mirror. IIRC, > Connectiva's modifications to apt-get will fix the "trust your DNS" > problem. Well, but you still have to trust your mirror and their admins? So how do you want to make sure that you can trust this mirror? Which modifications of apt are you talking about? What exactly did they modify? Did they change apt to not accept hostnames but only ip-address? > A kernel source is "clean" when it has the Debian kernel maintainer's > signature on it. A kernel binary is clean when the administrator: Which signature? If you download a debian package there's no signature on it that you could check. So how do you want to check a signature and make sure that there's no poisoned kernel-source on your debian mirror? > * gets a clean kernel source > * compiles it, and records the md5sum of the kernel with the "security > server" (or on a piece of paper). Of the kernel? What do you mean with kernel? Only vmlinuz? Or also the modules? Be more precise. > > > * Kernel "trojan scans" for all known nasty kernel code. > > > > How do you want to do this with a source that is about 117M big? You > > have any idea how long it will take? Also you could hide nasty code very > > good in it and which will be hard to catch (This is an assumption by > > myself, after having looked at some parts of the kernel-source.) > This service is not perfect, that needs to be made clear. However, it > is reasonable to state that a large fraction of break-ins will use a > "vanilla" rootkit, which might be detected even if the administrator > *hasn't* recorded the custom kernel's checksum. What do you define as "vanilla"? Also remeber that rootkits can change and become more sophisticated in t
Re: Debian audititing tool?
On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote: > On 00-12-21 Peter Eckersley wrote: > > Basically, I started reading the tripwire documentation, stopped, and > > thought "Debian ought to make this *much* simpler". It seemed that if I > > wanted to use tripwire, I'd need to tell it every time I was installing > > a new package. I'd then need to update a record on read-only media... > > Hm, looking at your statement above, I get the feeling that you have no > idea, what the purpose of tripwire really is. If you use it without a > read-only media to save the data too and rerunning it when you install > software on the machine, it won't be very helpful to track an intrusion. I understand the requirement for read-only media. Tripwire should give me a "clean" snapshot of a system. But when I administer a machine, I regularly make changes to the "clean" image. If I want tripwire to track this, I must do the following every time I want to update the system: 1. Reboot with a clean kernel 2. Run tripwire with my read-only record 3. Install my Debian packages 4. Update my read-only record My suggested alternative is a system which knows about official Debian packages, and will register that change as simply "installed/upgraded package XYZ". > > > Debsums seems to help a little bit - you can expect to catch some > > less-clueful intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand and > on the other hand you modify binaries so that the md5sum will still be > the same. Hence my comment. "Less-clueful" intruders won't modify /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, but will not help if the cracker is smart. > > > What I'd really like is this: > > > A CDROM or boot floppy with a clean kernel, which downloads a set of clean > > md5sums from a trusted server, and checks those. It could then produce a list > > of modified configuration files, which one would need to check by hand. > > So, how do you define clean kernel? Which kernel is really clean? How do > you define if a server is trustable and how do you make sure that no one > has put modified binaries on it? Of course, at some point, you have to make a leap of faith. ATM, most Debian users trust their DNS server and their Debian mirror. IIRC, Connectiva's modifications to apt-get will fix the "trust your DNS" problem. A kernel source is "clean" when it has the Debian kernel maintainer's signature on it. A kernel binary is clean when the administrator: * reboots the machine and uses the hypothetical auditing tool * gets a clean kernel source * compiles it, and records the md5sum of the kernel with the "security server" (or on a piece of paper). > > > * Kernel "trojan scans" for all known nasty kernel code. > > How do you want to do this with a source that is about 117M big? You > have any idea how long it will take? Also you could hide nasty code very > good in it and which will be hard to catch (This is an assumption by > myself, after having looked at some parts of the kernel-source.) This service is not perfect, that needs to be made clear. However, it is reasonable to state that a large fraction of break-ins will use a "vanilla" rootkit, which might be detected even if the administrator *hasn't* recorded the custom kernel's checksum. As new rootkits are observed "in the wild" (and a tool like this might help find them :), they can be added to the list of trojan signatures. This is closely analogous to the operation of virus scanners in M$ land. > > > * Debian security servers - these could keep a record of which config file > > changes you've okayed. They might also allow you to checksum customised > > What? Mirrors worldwide for your config-files? Use tripwire and you > don't need this. > > > * Heuristic analysis scripts to look for funny things in users' home > > directories, such as SETUID stuff and questionable aliases in .bashrc, for > > example (although this can never be perfect). > > You want to scan user-dirs without telling them that you do this? In > Germany you would better be careful with that as otherwise you could go > into jail for doing this. Please think about respecting the privacy of > your users. Do Windows sysadmins run their virus scanners with an "ignore users' files" flag? Have you added /home to your /etc/updatedb PRUNEPATHS? I am proposing the creation of a tool. Like any other tool, it might be abusable (not nearly as abusable as nmap, I might add). If using it in a particular way on a particular machine is inappropriate, then don't do it. > > > Does a tool like this exist already? If not, what do people think of the idea? > > No and I think on the one hand you have bit to much paranoia (Do you > have two entrance doors, grilled windows. a complete list of everything > in your house/flat in a safe by a lawyer? If no, I would suggest that > you think about your i
Re: Debian audititing tool?
On 00-12-21 Dan Hutchinson wrote: > I would agree with your comments except the scan of the Linux Kernel. Thanks. :) > You can use computer fornesics to scan the kernal against familiar trojan > and virus patterns realitively quickly and at least identify problem Hm, you know that some parts are written in ASM and that you could also use ASM in some parts of the kernel to protect malicous code? How could a fornesics (Hm, do you mean forensic?) detect this asm-code and know that it is malicous? Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
I would agree with your comments except the scan of the Linux Kernel. You can use computer fornesics to scan the kernal against familiar trojan and virus patterns realitively quickly and at least identify problem code. It would be up to you to review to see if it is good or bad code. The scans where something like 5 minutes for a 5GB drive. It is just scan the 1s and 0s. Dan Christian Kurz <[EMAIL PROTECTED]> wrote: > On 00-12-21 Peter Eckersley wrote: > > Basically, I started reading the tripwire documentation, stopped, > and > > thought "Debian ought to make this *much* simpler". It seemed that > if I > > wanted to use tripwire, I'd need to tell it every time I was installing > > a new package. I'd then need to update a record on read-only media... > > Hm, looking at your statement above, I get the feeling that you have > no > idea, what the purpose of tripwire really is. If you use it without > a > read-only media to save the data too and rerunning it when you install > software on the machine, it won't be very helpful to track an intrusion. > > > Debsums seems to help a little bit - you can expect to catch some > less-clueful > > intruders with it, but it doesn't help in general. > > debsums just uses md5sums which can be manipulated on the one hand > and > on the other hand you modify binaries so that the md5sum will still > be > the same. > > > What I'd really like is this: > > > A CDROM or boot floppy with a clean kernel, which downloads a set > of clean > > md5sums from a trusted server, and checks those. It could then produce > a list > > of modified configuration files, which one would need to check by > hand. > > So, how do you define clean kernel? Which kernel is really clean? How > do > you define if a server is trustable and how do you make sure that no > one > has put modified binaries on it? > > > * Kernel "trojan scans" for all known nasty kernel code. > > How do you want to do this with a source that is about 117M big? You > have any idea how long it will take? Also you could hide nasty code > very > good in it and which will be hard to catch (This is an assumption by > myself, after having looked at some parts of the kernel-source.) > > > * Debian security servers - these could keep a record of which config > file > > changes you've okayed. They might also allow you to checksum > customised > > What? Mirrors worldwide for your config-files? Use tripwire and you > don't need this. > > > * Heuristic analysis scripts to look for funny things in users' home > > directories, such as SETUID stuff and questionable aliases in .bashrc, > for > > example (although this can never be perfect). > > You want to scan user-dirs without telling them that you do this? In > Germany you would better be careful with that as otherwise you could > go > into jail for doing this. Please think about respecting the privacy > of > your users. > > > Does a tool like this exist already? If not, what do people think > of the idea? > > No and I think on the one hand you have bit to much paranoia (Do you > have two entrance doors, grilled windows. a complete list of everything > in your house/flat in a safe by a lawyer? If no, I would suggest that > you think about your ideas again.) and on the other hand you seem to > have missed the idea behind tools like tripwire. > > Ciao > Christian > -- > Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser > und größer als ein "Ja" um zu gefallen oder noch schlimmer, um > Schwierigkeiten zu umgehen. > -- Mahatma Gandhi > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-21 Peter Eckersley wrote: > Basically, I started reading the tripwire documentation, stopped, and > thought "Debian ought to make this *much* simpler". It seemed that if I > wanted to use tripwire, I'd need to tell it every time I was installing > a new package. I'd then need to update a record on read-only media... Hm, looking at your statement above, I get the feeling that you have no idea, what the purpose of tripwire really is. If you use it without a read-only media to save the data too and rerunning it when you install software on the machine, it won't be very helpful to track an intrusion. > Debsums seems to help a little bit - you can expect to catch some less-clueful > intruders with it, but it doesn't help in general. debsums just uses md5sums which can be manipulated on the one hand and on the other hand you modify binaries so that the md5sum will still be the same. > What I'd really like is this: > A CDROM or boot floppy with a clean kernel, which downloads a set of clean > md5sums from a trusted server, and checks those. It could then produce a list > of modified configuration files, which one would need to check by hand. So, how do you define clean kernel? Which kernel is really clean? How do you define if a server is trustable and how do you make sure that no one has put modified binaries on it? > * Kernel "trojan scans" for all known nasty kernel code. How do you want to do this with a source that is about 117M big? You have any idea how long it will take? Also you could hide nasty code very good in it and which will be hard to catch (This is an assumption by myself, after having looked at some parts of the kernel-source.) > * Debian security servers - these could keep a record of which config file > changes you've okayed. They might also allow you to checksum customised What? Mirrors worldwide for your config-files? Use tripwire and you don't need this. > * Heuristic analysis scripts to look for funny things in users' home > directories, such as SETUID stuff and questionable aliases in .bashrc, for > example (although this can never be perfect). You want to scan user-dirs without telling them that you do this? In Germany you would better be careful with that as otherwise you could go into jail for doing this. Please think about respecting the privacy of your users. > Does a tool like this exist already? If not, what do people think of the idea? No and I think on the one hand you have bit to much paranoia (Do you have two entrance doors, grilled windows. a complete list of everything in your house/flat in a safe by a lawyer? If no, I would suggest that you think about your ideas again.) and on the other hand you seem to have missed the idea behind tools like tripwire. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
