Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Sun, Nov 24, 2002 at 12:36:13AM +0100, Bernd Eckenfels wrote: On Sun, Nov 24, 2002 at 10:31:46AM +1100, Brian May wrote: You need to keep track (at both ends of the link) of the last sequence number sent. can we perhaps set up a mailinglist or discuss this on the mailinglist of grunt, it realy gets offtopic. Yeah, God forbid we talk about development on debian-DEVEL, instead of removing non-free or the cost of IDE vs. SCSI hard drives. -- G. Branden Robinson| Don't use nuclear weapons to Debian GNU/Linux | troubleshoot faults. [EMAIL PROTECTED] | -- US Air Force Instruction 91-111 http://people.debian.org/~branden/ | pgpiGNyGOYR36.pgp Description: PGP signature
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
In other news for Sat, Nov 23, 2002 at 11:18:22AM +1100, Brian May has been seen typing: The could remarkably slow the process down for slow batched based E-Mail systems. (it would appear to be a tradeoff of functionality/efficiency vs security). Isn't that a fairly accurate summary of *every* security measure? -- Brian May [EMAIL PROTECTED] -- Rens Houben / Shadur t'Kharn: Linux guru, programmer, geek, dreamer. GPG public key: http://swordbreaker.systemec.nl/~shadur/shadur.key.asc pgpT5uBTaxp1q.pgp Description: PGP signature
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
1. notice that oops, the cd burning script will do something evil if passed a certian type of iso. 2. send in a fixed script 3. run it Have you considered adding sequencing to the protocol? That is, if each of those mails above had a sequence number in them, the receiver would not execute (3) until it had done (2). signature.asc Description: This is a digitally signed message part
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 06:22:53PM -0600, Adam Heath wrote: In case it hasn't been mentioned, one could use sequence numbers, ala tcp. You need to keep track (at both ends of the link) of the last sequence number sent. Or, if you allow emails to be sent from multiple hosts, you need to keep track of the last sequence number from each host. This is very much similar to TCP. However, unlike TCP, there is no concept of a connection or session (unless you create one), so sequence numbers have to be kept indefinitely. hmmm... come to think of it, session tracking might be an interesting idea. sessions could also keep track of environment variables and/or CWD. eg (one email by line, server is S, sender is C): C -- S: open session S -- C: session X is open C -- S: session X command 1 execute cd /tmp S -- C: session X command 1 output was (OPTIONAL) C -- S: session X command 2 execute rm * S -- C: session X command 2 output was (OPTIONAL) C -- S: session X command 3 close S -- C: session X is closed, session text was ... OR if received in duplicates or out of order: C -- S: open session S -- C: session X is open C -- S: session X command 2 execute rm * S -- C: session X command 2 received out of order; delayed. (OPTIONAL) C -- S: session X command 1 execute cd /tmp S -- C: session X command 1 output was (OPTIONAL) C -- S: session X command 1 execute cd /tmp S -- C: session X command 1 received duplicated. (OPTIONAL) S -- C: session X command 2 output was (OPTIONAL) (after n hours) S -- C: session X is closed, session text was ... C -- S: session X command 3 execute cd /tmp S -- C: session X command 3 session was closed. (OPTIONAL) Except for the optional warnings that something has gone wrong, I think this is very similar to TCP (except only one sequence per message is all thats really required). You just need to make sure it is not possible to replay the open session command; this could be done by having the session number (X) a sequence number that is always incremented by one. So even if a session open is replayed, the session number would be different, making it useless to replay the commands. I think the worst an attacker could do with this protocol would be to delay the last commands until after the session expires. This is effectively a Denial-Of-Service attack, which is possible even with ssh (eg. pull the plug out of the network), and nothing you can really do about it. This effectively means it is a challange/response protocol like somebody else suggested, but the challange response is only required once per session. Any errors are entirely my own ;-). -- Brian May [EMAIL PROTECTED]
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Sun, Nov 24, 2002 at 10:31:46AM +1100, Brian May wrote: You need to keep track (at both ends of the link) of the last sequence number sent. can we perhaps set up a mailinglist or discuss this on the mailinglist of grunt, it realy gets offtopic. Greetings Bernd
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
Hi, Jason == Jason Gunthorpe [EMAIL PROTECTED] writes: Jason PGP signatures have a signature ID and a date that are ment to be used to Jason prevent against replay attacks. I forget the exact details but there is a Jason gpg mode that prints it out. The db.debian.org gateways all make use of Jason it. Indeed, as does the voting machinery. I was going to post example code here, but the example got too huge (email me if you want a copy). Replay attacks can be thwarted by a simple check on the server. manoj -- Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
Le ven 22/11/2002 à 05:41, Brian May a écrit : A secure way to handle this would be a challenge/response authentification, or a system similar to SSH's one-time passwords. No, I think it is an inherent problem with using E-Mail for such things. As long as E-Mail is used, the possibility exists that the E-Mail will get delayed. If the E-Mail gets delayed it is not possible to cancel it, it has already been sent. That's why I suggest using either a challenge/response authentification (if the mail is lost, you have to ask for a new challenge and the previous mail won't be accepted if it is delayed), or one-time passwords (every time you use a OTP, all previous passwords are revoked). -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 03:35:11PM +1100, Brian May wrote: 30 days seems like an awfully long time... I would have though rejecting any requests, say an hour old would be better... So, if you did issue an halt command, the worst an attacker could do would be to delay execution by one hour, not 30 days. It's configurable. An hour might be too little if, for instance, things are travelling across UUCP that run a few times a week. -- John
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 12:55:07AM +0100, Josselin Mouette wrote: message from being sent, and keep it for another day. Seeing your computer doesn't halt, you resend the message, and the attacker has 30 days to use what he has stolen. So you set the window to 2 days, or 15 minutes, or whatever. But really, 'halt' is not really the kind of command this is designed to run. And couldn't, unless you either used sudo or did something nasty to make it run as root. It's more designed to do things like take this 650MB ISO and go burn it whenever or run this batch processing command. A secure way to handle this would be a challenge/response authentification, or a system similar to SSH's one-time passwords. How can you respond if you are communicating asynchronously?
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 12:43:28AM -0500, Joey Hess wrote: This is interesting. I've been planning to add play-by-mail support to my mooix moo, but have held off because I didn't want to tackle doing it securely. But if I can just use grunt and it turns out to be secure.. that'd be sweet. I hope that grunt lets you just compose commands with a standard mailer, without having to run some command on your system to set up the random block John mentions. For my (very specific) purposes, it would be nice if it could be used without gpg, from any system that can send and receive mail. GPG is integral to grunt's security, so you won't be able to run it without GPG. You invoke GRUNT with simple commands like: gruntsend file.txt [EMAIL PROTECTED] destination/file.txt or gruntrun [EMAIL PROTECTED] 'cdrecord -v dev=1,1,0 -eject' file.iso or gruntrun [EMAIL PROTECTED] somebatchjob.sh That is, it's mostly designed for things like batch jobs -- things that don't depend on being executed in any particular order. When you run gruntsend or gruntrun, you'll have to enter in your GPG passphrase to sign the message. The receiver has the aging restrictions described before. Though it can be tuned -- you could set it down to 60 minutes if that's more appropriate for your setting. I'm also still tweaking things yet until I make the first release -- I want to get the protocol set before that. I am confident that Grunt is secure. There is no way to make your system execute commands that you did not request, nor for an attacker to use a replay attack. It is possible, as some have brought up, to delay a command. Though you can set the window in which commands are allowed, and can set it to whatever you like. This could me especially amusing if the first, delayed email was: cd /tmp And the second was: rm -rf * Grunt doesn't preserve any notion of a session (think of it sort of like 'at', maybe?) It's more designed to be able to execute 'batch' type of commands. That is, here's this chunk of data, go do something intensive with it. It's also designed to help with people that need to use a modified sneakernet to get data around -- ie, a slow connection one place, fast one other place, and a laptop. -- John
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 12:24:34AM -0500, Joey Hess wrote: After verifying the signature on the data, the receiver does some sanity checks. One of the checks is doing an md5sum over the entire file (remember, this includes both the headers and the payload). If it has seen the same md5sum in the last 60 days, it rejects the request. If the date of the request was more than 30 days ago, it rejects the request. Hold on, if you're md5summing the headers, what is to stop an attacker from modifying the subject, and using an intercepted, gpg-signed body to repeat the command? It's an md5sum over the entire file. The file includes both the headers and the body. -- John
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Thu, Nov 21, 2002 at 10:47:46PM -0700, Jason Gunthorpe wrote: PGP signatures have a signature ID and a date that are ment to be used to prevent against replay attacks. I forget the exact details but there is a gpg mode that prints it out. The db.debian.org gateways all make use of it. I didn't know about that. I'll look into it. It would make things a bit easier, I think. Thanks for pointing it out. BTW for those interested, I hope to put out the first release early next week. I'm still ironing out a few of these details and have to write the e-mail support and some documentation yet, but you can check it out at the subversion repository at svn.complete.org. -- John
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
John Goerzen wrote: Grunt doesn't preserve any notion of a session It doesn't need to: the unix filesystem already does. I said that was a contrived example, but I'm sure you will find some real ones eventually. Slightly less contrived: 1. notice that oops, the cd burning script will do something evil if passed a certian type of iso. 2. send in a fixed script 3. run it You really don't want step 2 to be intercepted here either. -- see shy jo pgpv5hOluWMzD.pgp Description: PGP signature
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 12:43:28AM -0500, Joey Hess wrote: This could me especially amusing if the first, delayed email was: cd /tmp And the second was: rm -rf * (Dumb contrived example, but you get the idea.) I think the lesson here is that grunt is not a transparent replacement, for say ssh, but a tool that you have to think about using before using it. So, you could include both commands in the one email, and it would be OK. Or you could include the full path in the second E-Mail, and assuming it isn't tricked by any of these race conditions surrounding /tmp, then it would be OK too. Yes, it is a dumb contrived example, I don't think grunt would preserve the current working directory... So you might have serious problems even if the order of the messages was correct. -- Brian May [EMAIL PROTECTED]
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 10:32:22AM +0100, Josselin Mouette wrote: That's why I suggest using either a challenge/response authentification (if the mail is lost, you have to ask for a new challenge and the previous mail won't be accepted if it is delayed), or one-time passwords (every time you use a OTP, all previous passwords are revoked). Presumably you would have to send 1 E-Mail (challange), wait for the response, and then send the next E-Mail. The could remarkably slow the process down for slow batched based E-Mail systems. (it would appear to be a tradeoff of functionality/efficiency vs security). -- Brian May [EMAIL PROTECTED]
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Sat, 23 Nov 2002, Brian May wrote: On Fri, Nov 22, 2002 at 12:43:28AM -0500, Joey Hess wrote: This could me especially amusing if the first, delayed email was: cd /tmp And the second was: rm -rf * (Dumb contrived example, but you get the idea.) I think the lesson here is that grunt is not a transparent replacement, for say ssh, but a tool that you have to think about using before using it. In case it hasn't been mentioned, one could use sequence numbers, ala tcp.
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 09:47:48AM -0600, John Goerzen wrote: On Fri, Nov 22, 2002 at 12:24:34AM -0500, Joey Hess wrote: After verifying the signature on the data, the receiver does some sanity checks. One of the checks is doing an md5sum over the entire file (remember, this includes both the headers and the payload). If it has seen the same md5sum in the last 60 days, it rejects the request. If the date of the request was more than 30 days ago, it rejects the request. Hold on, if you're md5summing the headers, what is to stop an attacker from modifying the subject, and using an intercepted, gpg-signed body to repeat the command? It's an md5sum over the entire file. The file includes both the headers and the body. No, I think the question might be what if the MD5SUM is different but the GPG signature is the same? I think it depends on the method used to sign the message, some methods sign the headers, some don't. So if I manually sign a message, and include it in the body of this message, it won't protect the headers in anyway. Somebody could alter the headers, resulting in the md5sum becomming altered, and the message won't be detected as a replay. Also, to prevent another possible (maybe obvious) attack; make sure your clock is set correctly (and not some time in the future) before sending a email... -- Brian May [EMAIL PROTECTED]
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, 2002-11-22 at 06:36, Alexander Neumann wrote: John Goerzen wrote: GRUNT is a tool to let you execute commands remotely, offline. It will also let you copy files to a remote machine. How did you solve the problem of re-sending such mails? Say, Joe Evil Cracker is able to catch a command mail containing halt. Will he be able to shutdown my machine every time he want? I can't speak for GRUNT (having no first-hand knowledge of it) but a couple of ways to do this spring to mind. For example, timestamp every message internally (so the timestamp is inside the GPG payload, not just in the header) and keep a record at the recipient end of timestamps of all executed commands. Ignore duplicates. Alternatively a random character string could be used, but timestamps might give other benefits (for eg, ignore messages older than 5 minutes). Jonathan Oxer Ph +61 3 9723 9399 / Fx +61 3 9723 4899 GPG key: http://www.ivt.com.au/gpg/jon.oxer.gpg signature.asc Description: This is a digitally signed message part
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Thu, Nov 21, 2002 at 08:36:37PM +0100, Alexander Neumann wrote: John Goerzen wrote: GRUNT is a tool to let you execute commands remotely, offline. It will also let you copy files to a remote machine. How did you solve the problem of re-sending such mails? Say, Joe Evil Cracker is able to catch a command mail containing halt. Will he be able to shutdown my machine every time he want? Each message has its payload and its header information (what command to run, what file is being copied, etc.) GPG-signed. (The two are combined together to a single file, which is GPG signed as a whole.) This header information includes, among other things: 1. Date time the file was prepared 2. pid that created the file 3. 2048 bits of random data After verifying the signature on the data, the receiver does some sanity checks. One of the checks is doing an md5sum over the entire file (remember, this includes both the headers and the payload). If it has seen the same md5sum in the last 60 days, it rejects the request. If the date of the request was more than 30 days ago, it rejects the request. Therefore, the sender is able to reissue the halt command legitimately as often as he/she wants, since the random bits time will ensure different md5sums on the recipient. But replay attacks will be useless since the recipient will have seen the request already, and will reject it. -- John
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
Le jeu 21/11/2002 à 23:12, John Goerzen a écrit : After verifying the signature on the data, the receiver does some sanity checks. One of the checks is doing an md5sum over the entire file (remember, this includes both the headers and the payload). If it has seen the same md5sum in the last 60 days, it rejects the request. If the date of the request was more than 30 days ago, it rejects the request
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Thu, Nov 21, 2002 at 04:12:42PM -0600, John Goerzen wrote: After verifying the signature on the data, the receiver does some sanity checks. One of the checks is doing an md5sum over the entire file (remember, this includes both the headers and the payload). If it has seen the same md5sum in the last 60 days, it rejects the request. If the date of the request was more than 30 days ago, it rejects the request. 30 days seems like an awfully long time... I would have though rejecting any requests, say an hour old would be better... So, if you did issue an halt command, the worst an attacker could do would be to delay execution by one hour, not 30 days. -- Brian May [EMAIL PROTECTED]
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 12:55:07AM +0100, Josselin Mouette wrote: What if the attacker can intercept the messages ? He can prevent a message from being sent, and keep it for another day. Seeing your computer doesn't halt, you resend the message, and the attacker has 30 days to use what he has stolen. A secure way to handle this would be a challenge/response authentification, or a system similar to SSH's one-time passwords. No, I think it is an inherent problem with using E-Mail for such things. As long as E-Mail is used, the possibility exists that the E-Mail will get delayed. If the E-Mail gets delayed it is not possible to cancel it, it has already been sent. An E-Mail could go missing due to bad mail configuration, could get delayed due to a link going down, or deliberately (for example). When the remote hosts does receive the E-Mail, it has no way of knowing if the submitter still wants it to be executed or not. Maybe it might be possible to send a cancel or revoke message to the server, but presumably if initial E-Mail got delayed, the cancel/revoke message would be delayed too. -- Brian May [EMAIL PROTECTED]
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
John Goerzen wrote: After verifying the signature on the data, the receiver does some sanity checks. One of the checks is doing an md5sum over the entire file (remember, this includes both the headers and the payload). If it has seen the same md5sum in the last 60 days, it rejects the request. If the date of the request was more than 30 days ago, it rejects the request. Hold on, if you're md5summing the headers, what is to stop an attacker from modifying the subject, and using an intercepted, gpg-signed body to repeat the command? -- see shy jo pgpOU8IXaGsID.pgp Description: PGP signature
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
This is interesting. I've been planning to add play-by-mail support to my mooix moo, but have held off because I didn't want to tackle doing it securely. But if I can just use grunt and it turns out to be secure.. that'd be sweet. I hope that grunt lets you just compose commands with a standard mailer, without having to run some command on your system to set up the random block John mentions. For my (very specific) purposes, it would be nice if it could be used without gpg, from any system that can send and receive mail. Brian May wrote: No, I think it is an inherent problem with using E-Mail for such things. As long as E-Mail is used, the possibility exists that the E-Mail will get delayed. If the E-Mail gets delayed it is not possible to cancel it, it has already been sent. An E-Mail could go missing due to bad mail configuration, could get delayed due to a link going down, or deliberately (for example). This could me especially amusing if the first, delayed email was: cd /tmp And the second was: rm -rf * (Dumb contrived example, but you get the idea.) You could possibly do stuff with seqence numbers though to prevent this. If every command you sent was a reply to a message from the grunt server (the response to the last command), the server could generate a new number each time. Something like this: From: me Subject: hi, I want a grunt session From: grunt server Subject: your session started Be sure to reply to this message to include this data -- Session-id: 240943 Sequence-number: 1 From: me Subject: my first command cd /tmp Be sure to reply to this message to include this data -- Session-id: 240943 Sequence-number: 1 From: grunt server Subject: re: my first command cd /tmp pwd: /tmp Be sure to reply to this message to include this data -- Session-id: 240943 Sequence-number: 2 From: me Subject: my second command rm -rf * Session-id: 240943 Sequence-number: 2 If the cd command is intercepted or delayed, then I'll notice that the server is not responding back. I could then try to resend it, superceding my old command (which the server would discard if it got it, since its sequence number for this session would increase). Unless I'm terminally stupid, I cannot send the second, dependant rm command until the first command gets run. I'd have to forge the sequence number (2). The server could even protect from this by using randomly increasing sequence numbers, at-la-tcp. I could also try to cancel the whole session, with another mail. If the mail got through, that would prevent the interceptor from feeding it to the server at a later date. However, they could just intercept the cancel mail too. That's about the time I think I'd reach for out of band communication. -- see shy jo pgpX615Hu6g6v.pgp Description: PGP signature
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, 22 Nov 2002, Joey Hess wrote: After verifying the signature on the data, the receiver does some sanity checks. One of the checks is doing an md5sum over the entire file (remember, this includes both the headers and the payload). If it has seen the same md5sum in the last 60 days, it rejects the request. If the date of the request was more than 30 days ago, it rejects the request. Hold on, if you're md5summing the headers, what is to stop an attacker from modifying the subject, and using an intercepted, gpg-signed body to repeat the command? PGP signatures have a signature ID and a date that are ment to be used to prevent against replay attacks. I forget the exact details but there is a gpg mode that prints it out. The db.debian.org gateways all make use of it. Jason
