From erh+sudo at nimenees.com Thu May 1 11:51:27 2008 From: erh+sudo at nimenees.com (Eric Haszlakiewicz) Date: Thu, 1 May 2008 10:51:27 -0500 Subject: [sudo-workers] lack of mailling list security Message-ID: <20080501155127.GA2073@nimenees.com> Does anyone else fine it ironic that a mailing list for a very security oriented program sends out everyone's passwords in plain text emails? Logging into the website isn't all that secure either. The certificate for the site is for a completely different hostname, but it doesn't matter because even if you type in "https", the form on that page _forces_ you back to a non-SSL login. eric From Todd.Miller at courtesan.com Thu May 1 13:22:13 2008 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Thu, 01 May 2008 13:22:13 -0400 Subject: [sudo-workers] lack of mailling list security In-Reply-To: Your message of "Thu, 01 May 2008 10:51:27 CDT." <20080501155127.GA2073@nimenees.com> References: <20080501155127.GA2073@nimenees.com> Message-ID: <200805011722.m41HMDFS022054@tex.courtesan.com> In message <20080501155127.GA2073 at nimenees.com> so spake Eric Haszlakiewicz (erh+sudo): > Does anyone else fine it ironic that a mailing list for a very security > oriented program sends out everyone's passwords in plain text emails? This is really no less secure than interacting with a mailing list manager by sending a tokens back and forth in plain text. If you can sniff the traffic and want to subscribe/unsubscribe someone from a list you could the same thing. > Logging into the website isn't all that secure either. The certificate > for the site is for a completely different hostname, but it doesn't matter > because even if you type in "https", the form on that page _forces_ you > back to a non-SSL login. The cert is for the "real" name of the web server. I suppose I could add a separate cert for each vhost, though that won't solve the problem where mailman directs you to an http page. - todd From erh+sudo at nimenees.com Thu May 1 16:50:59 2008 From: erh+sudo at nimenees.com (Eric Haszlakiewicz) Date: Thu, 1 May 2008 15:50:59 -0500 Subject: [sudo-workers] lack of mailling list security In-Reply-To: <200805011722.m41HMDFS022054@tex.courtesan.com> References: <20080501155127.GA2073@nimenees.com> <200805011722.m41HMDFS022054@tex.courtesan.com> Message-ID: <20080501205059.GA13341@nimenees.com> On Thu, May 01, 2008 at 01:22:13PM -0400, Todd C. Miller wrote: > In message <20080501155127.GA2073 at nimenees.com> > so spake Eric Haszlakiewicz (erh+sudo): > > > Does anyone else fine it ironic that a mailing list for a very security > > oriented program sends out everyone's passwords in plain text emails? > > This is really no less secure than interacting with a mailing list > manager by sending a tokens back and forth in plain text. If you > can sniff the traffic and want to subscribe/unsubscribe someone > from a list you could the same thing. It is MUCH less secure because actual passwords provide more information than a random key. Many people use the same (or similar) password on multiple websites. Given that, it's rather irresponsible to be sending their passwords in plaintext. On the other hand, I just looked at the sign up form, and there's a clear warning there about this, so for those people that care, they can choose a password that doesn't relate to anything else. Of course, I still think it's better to be more secure by default, rather than depending on the person signing up to do the right thing. > > Logging into the website isn't all that secure either. The certificate > > for the site is for a completely different hostname, but it doesn't matter > > because even if you type in "https", the form on that page _forces_ you > > back to a non-SSL login. > > The cert is for the "real" name of the web server. I suppose I > could add a separate cert for each vhost, though that won't solve > the problem where mailman directs you to an http page. I don't think you can do that if you're using vhosts. By the time the web server figures out which site you're accessing, a secure connection must already have been set up. oh well, I guess you can't fix this. Fixing the login should be as simple as making the action on that form be a relative url, or hard coding it to https://hostname/.... At the very least, I think the login form should have a warning saying that it isn't secure, like the signup page does. eric From rea-sudo at codelabs.ru Fri May 2 07:24:08 2008 From: rea-sudo at codelabs.ru (Eygene Ryabinkin) Date: Fri, 2 May 2008 15:24:08 +0400 Subject: [sudo-workers] lack of mailling list security In-Reply-To: <200805011722.m41HMDFS022054@tex.courtesan.com> References: <20080501155127.GA2073@nimenees.com> <200805011722.m41HMDFS022054@tex.courtesan.com> Message-ID: Todd, good day. Thu, May 01, 2008 at 01:22:13PM -0400, Todd C. Miller wrote: > > Logging into the website isn't all that secure either. The certificate > > for the site is for a completely different hostname, but it doesn't matter > > because even if you type in "https", the form on that page _forces_ you > > back to a non-SSL login. > > The cert is for the "real" name of the web server. I suppose I > could add a separate cert for each vhost, though that won't solve > the problem where mailman directs you to an http page. There is no point in adding another certificates: SSL connection is established prior to the vhost recognition. But you can add all your hostnames to the certificate's subjectAltName field. They should be in the dNSName format. The following links can be of interest: http://nils.toedtmann.net/pub/subjectAltName.txt http://wiki.cacert.org/wiki/VhostTaskForce You will have to resign the certificate at the CA. -- Eygene From Todd.Miller at courtesan.com Thu May 8 17:55:48 2008 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Thu, 08 May 2008 17:55:48 -0400 Subject: [sudo-workers] sudo 1.7.0rc1 released Message-ID: <200805082155.m48LtmQF020938@tex.courtesan.com> This is the first release candidate of sudo version 1.7.0. I'd love to hear reports of success (or failure!) in real-world environments. Download links: http://www.sudo.ws/sudo/dist/beta/sudo-1.7.0.tar.gz ftp://ftp.sudo.ws/pub/sudo/beta/sudo-1.7.0.tar.gz Changes from Sudo 1.7b4: * A sudo-specific environment file may be specified by the env_file option, with the same syntax as /etc/environment. This is available on all systems, even those that do not natively support /etc/environment. * More fixes to the AIX resource limit setting code. * Closed a few memory leaks in the parser found by valgrind. * Fixed a problem in "sudo -l" mode where a NOPASSWD tag would not be displayed in some circumstances. * Fixed a typo in the code that reads /etc/ldap.secret. What's new in Sudo 1.7? * Rewritten parser that converts sudoers into a set of data structures. This eliminates a number of ordering issues and makes it possible to apply sudoers Defaults entries before searching for the command. It also adds support for per-command Defaults specifications. * Sudoers now supports a #include facility to allow the inclusion of other sudoers-format files. * Sudo's -l (list) flag has been enhanced: o applicable Defaults options are now listed o a command argument can be specified for testing whether a user may run a specific command. o a new -U flag can be used in conjunction with "sudo -l" to allow root (or a user with "sudo ALL") list another user's privileges. * A new -g flag has been added to allow the user to specify a primary group to run the command as. The sudoers syntax has been extended to include a group section in the Runas specification. * A uid may now be used anywhere a username is valid. * The "secure_path" run-time Defaults option has been restored. * Password and group data is now cached for fast lookups. * The file descriptor at which sudo starts closing all open files is now configurable via sudoers and, optionally, the command line. * Visudo will now warn about aliases that are defined but not used. * The -i and -s command line flags now take an optional command to be run via the shell. Previously, the argument was passed to the shell as a script to run. * Improved LDAP support. SASL authentication may now be used in conjunction when connecting to an LDAP server. The krb5_ccname parameter in ldap.conf may be used to enable Kerberos. * Support for /etc/nsswitch.conf. LDAP users may now use nsswitch.conf to specify the sudoers order. E.g.: sudoers: ldap files to check LDAP, then /etc/sudoers. The default is "files", even when LDAP support is compiled in. This differs from sudo 1.6 where LDAP was always consulted first. * Support for /etc/environment on AIX and Linux. If sudo is run with the -i flag, the contents of /etc/environment are used to populate the new environment that is passed to the command being run. * If no terminal is available or if the new -A flag is specified, sudo will use a helper program to read the password if one is configured. Typically, this is a graphical password prompter such as ssh-askpass. * A new Defaults option, "mailfrom" that sets the value of the "From:" field in the warning/error mail. If unspecified, the login name of the invoking user is used. * A new flag, -n, may be used to indicate that sudo should not prompt the user for a password and, instead, exit with an error if authentication is required.