Since the maintainer password is send in cleartext with the x_command interface of SmartList I made some scripts and patches to enable SmartList to process x_commands with encrypted passwords. The encryption mechanismn is Twofish. Encryption can be enabled/disabled with a variable in rc.custom. Two small patches for rc.request and the x_command script are necessary.
Grab it at
ftp://ftp.pure.ch/smartlist/
It's called xc_sec-0.1.tar.gz.
Werner
On Sun, Apr 14, 2002 at 02:40:10PM +0200, Werner Reisberger wrote:
Since the maintainer password is send in cleartext with the x_command interface of SmartList I made some scripts and patches to enable SmartList to process x_commands with encrypted passwords.
Am I missing something here? It's true that this system prevents someone from discovering the password by intercepting email; however, the token which the email interceptor discovers is just as good as a password, in that it can be used to cause the execution of X-Commands.
I suggest that a truly secure system would have authentication tokens which were only valid on a single occasion; perhaps the system should randomly change the X-Command password after each command, and email the new password to the maintainer address. (Ideally, of course, it wouldn't even do that; the maintainer would have a list of passwords which would be used in order, and have some secure means of getting more passwords.)
In the absence of a truly cryptographically secured system - such as connecting to the list server with SSH - I fear this is the best that can be done.
Roger
At 7:30 AM -0400 4/15/02, Roger Burton West is rumored to have typed:
In the absence of a truly cryptographically secured system - such as connecting to the list server with SSH - I fear this is the best that can be done.
Er...with sincere apologies to Werner and Roger, I'm a little bewildered by all of this. It's cool and all, but if a mailing list _needs_ to be truly secure (I'm not sure I quite understand _why,_ since it's...well...just a mailing list), then X-Commands should be shut down completely and all maintenance can easily be done through an SSH shell. (Don't have SSH? Install it NOW. Can't install because you don't root the box? How secure do you think ANY of your stuff is?) Although I'd maintain that SmartList isn't really designed to protect its data to the same level that one would (should, anyway) protect credit card information, anyway, so I'm not sure even _that_ argument is moot...look at the number of times setting up web-based X-Command interfaces comes up on this list because the "newbies" can't figure out the proper format for the command, let alone placing it on the first line of a non-multipart message so SmartList can append it to the header. Wrap a web interface on a secure web page and drop X-Commands that don't come from localhost and you've got a reasonably "secure" X-Command system without rotating passwords or list keysets.
I took a somewhat different approach to a different "problem." I didn't much like the Approval: system for moderated lists (this is way back in the days before the moderator_PASSWORD var, understand), so thanks to open-source I hacked a mildly different one that uses a password in the Subject: header field for those lists which are moderated. It is NOT "secure," it's just different enough that someone familiar with SmartList who didn't crack my server or sniff right outside it couldn't easily approve a message (rc.local.s00 contains a recipe that drops any Approved: headers straighaway - and if they crack my server, I have bigger problems than the mailing lists!). But I didn't do it to "securely" protect the list, rather to make it less trivial for a user to get around me...anyone who wanted to spend a lot of time and energy could certainly get past it, and probably root the box as well no matter how hard I try to keep up with updates and patches. But why in heavens name _would_ anyone spend that amount of time just so they could post a message?
It's a matter of cost/benefit. Someone could spend a lot of time and energy sniffing outside my server, to get...what? An X-Command password? So they could do...what? Manually subscribe people? Isn't it easier to find a China open relay to annoy people?
Again, I'm not exactly sure what problem this is attempting to solve. Heck, a lot of the lists discussed here are on shared machines anyway - secure the X-Command, but screw the file permissions and allow everyone else on the machine (and in some cases I've seen, _off_ the machine with a web browser if you know its path!) to read the dist list anyway?
Charlie
On Mon, Apr 15, 2002 at 12:30:01PM +0100, Roger Burton West wrote:
Am I missing something here? It's true that this system prevents someone from discovering the password by intercepting email; however, the token which the email interceptor discovers is just as good as a password, in that it can be used to cause the execution of X-Commands.
That's true. I made this silly mistake, not thinking about the reusability of the cipher.
I suggest that a truly secure system would have authentication tokens which were only valid on a single occasion; perhaps the system should randomly change the X-Command password after each command, and email the new password to the maintainer address. (Ideally, of course, it wouldn't even do that; the maintainer would have a list of passwords which would be used in order, and have some secure means of getting more passwords.)
I think there is a less cumbersome solution: The maintainer password is encrypted together with a sequence number. On the list server the password will be decrypted together with the sequence number. If the stored sequence number is 1 smaller than the actual one the xcommand will be executed. Otherwise the maintainer will receive an email with the current sequence number. Someone intercepting the sequence number gains nothing. By this means the cipher cannot be reused.
ssh is fine and I use it to access a list server but I like it more to use my doxcommand script on the command line to do some admin work. It's fast and easy - but insecure.
Werner
On Mon, Apr 15, 2002 at 09:52:09PM +0200, Werner Reisberger wrote:
I think there is a less cumbersome solution: The maintainer password is encrypted together with a sequence number. [snip explanation]
That sounds good to me, as long as one trusts the strength of Twofish (which at this point is a reasonable thing to do). In answer to Charlie: it's true that this won't be appropriate in a lot of cases, and personally I use ssh rather than X-Command for my list-admin, but it won't make the security situation any worse and the overhead is fairly low.
Roger
--On Monday, April 15, 2002 9:52 PM +0200 Werner Reisberger werner@pure.ch wrote:
I suggest that a truly secure system would have authentication tokens which were only valid on a single occasion; perhaps the system should randomly change the X-Command password after each command, and email the new password to the maintainer address. (Ideally, of course, it wouldn't even do that; the maintainer would have a list of passwords which would be used in order, and have some secure means of getting more passwords.)
I think there is a less cumbersome solution: The maintainer password is encrypted together with a sequence number. On the list server the password will be decrypted together with the sequence number. If the stored sequence number is 1 smaller than the actual one the xcommand will be executed. Otherwise the maintainer will receive an email with the current sequence number. Someone intercepting the sequence number gains nothing. By this means the cipher cannot be reused.
How about making the password a key (or access to) to the encryption, and *not* transmitting it, but encrypt the xcommand instead? It would allow an attacker to redo an intercepted command, but only that one (and hopefully they don't know what it is.) Put a time stamp in and they can't even do that.
Of course, that is only a couple of steps short of a full public/private key system...
Daniel T. Staal
------------------------------------------------------------------------ This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ------------------------------------------------------------------------
In article 20020415113001.GA12632@firedrake.org, Roger Burton West roger@firedrake.org writes:
On Sun, Apr 14, 2002 at 02:40:10PM +0200, Werner Reisberger wrote:
Since the maintainer password is send in cleartext with the x_command interface of SmartList I made some scripts and patches to enable SmartList to process x_commands with encrypted passwords.
Am I missing something here? It's true that this system prevents someone from discovering the password by intercepting email; however, the token which the email interceptor discovers is just as good as a password, in that it can be used to cause the execution of X-Commands.
This is true, but is there any reason to believe that network sniffing presently poses any threat to mailing list management? Sniffers of passwords generally have bigger fish to fry. I have never yet seen someone's mailing list password compromised in this fashion.
Zitat von Tim Pierce twp@rootsweb.com:
This is true, but is there any reason to believe that network sniffing presently poses any threat to mailing list management? Sniffers of passwords generally have bigger fish to fry. I have never yet seen someone's mailing list password compromised in this fashion.
Maybe I am paranoid but network sniffing is nowadays easy to use for every kid and I just don't want to give anyone the possibility to unsub all of my list members. I also don't hear of any incidents like this but I don't want to be surprised some day.
Anyway, I am going to offer the SmartList users an addon. You can use it or not. You can even enable/disable it after installation with a rc.custom toggle.
Werner
smartlist@lists.rwth-aachen.de
-
Charlie Summers -
Daniel Staal -
Roger Burton West -
Tim Pierce -
Werner Reisberger