Re: Machine-readable form for debian security advisories
On Thu, 12 Aug 2004 03:38 pm, Lupe Christoph wrote: On Thursday, 2004-08-12 at 14:26:44 +1000, Joshua Goodall wrote: Therefore I see a need for a machine readable DSA format. I know there's a defined format to the current header, but I'd like to expand on that. It will look something like: Please do not invent yet anoither format if you can avoid it. You don't mention VuXML (http://www.vuxml.org/), so I suppose you did not know it. Please have a look there. As I understand it, VuXML has a slightly different semantic. It expresses that specified binary package versions will have a certain vulnerability and implies they should be deinstalled or upgraded to some version for which the vulnerability does not exist. The DSA series always gives less than information and states you must upgrade to the version listed. VuXML also lacks metadata fields for specifying architecture limitations or restriction to different distributions of the system. They are required because the Debian security team generally backports fixes and thereby creates their own branch of the package. VuXML only distinguishes distributions using the system element, which is a sibling of the package element. That structure is correct for the *BSDs but not for Debian. e.g. I will probably use an extension of the vocabulary: --- vuxml-model-11.mod.orig 2004-04-03 01:29:56.0 +1000 +++ vuxml-model-11.mod 2004-08-12 17:21:11.0 +1000 @@ -57,6 +57,8 @@ !ENTITY % vuxml.system.qname %vuxml.pfx;system !ENTITY % vuxml.name.qname %vuxml.pfx;name !ENTITY % vuxml.range.qname %vuxml.pfx;range +!ENTITY % vuxml.distribution.qname %vuxml.pfx;distribution +!ENTITY % vuxml.architecture.qname %vuxml.pfx;architecture !ENTITY % vuxml.lt.qname %vuxml.pfx;lt !ENTITY % vuxml.le.qname %vuxml.pfx;le !ENTITY % vuxml.gt.qname %vuxml.pfx;gt @@ -197,6 +199,8 @@ !ELEMENT %vuxml.package.qname; ( ( %vuxml.name.qname; )+, + ( %vuxml.distribution.qname; )?, + ( %vuxml.architecture.qname; )+, ( %vuxml.range.qname; )+ ) !ATTLIST %vuxml.package.qname; %vuxml.Common.attrib; (untested, but you get the idea) to produce affects package distributionstable/distribution architecturei386/architecture architecturearm/architecture architectureia64/architecture architecturehppa/architecture architecturem68k/architecture architecturemips/architecture architecturemipsel/architecture architectures390/architecture architecturesparc/architecture namelibpng2/name rangelt1.0.12-3.woody.7/lt/range /package or package distributionstable/distribution architectureany/architecture namelibpng2-dev/name rangelt1.0.12-3.woody.7/lt/range /package etc. These nits aside, I can probably use VuXML for my project, even if it means extending the DTD. Thanks for pointing it out! -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgptYMFLgexSN.pgp Description: signature
Machine-readable form for debian security advisories
I have several hundred debian instances to care for, and they are monitored via Nagios. I would like to institute a regular test that checks each box against a list of security advisories, without running apt-get update several times a day on 300 boxes. Therefore I see a need for a machine readable DSA format. I know there's a defined format to the current header, but I'd like to expand on that. It will look something like: DSA: 536-1 Title: New libpng, libpng3 packages fix multiple vulnerabilities Date: 20040804 Upgrade-required: simple Vulnerability: several Problem-Type: local/remote Debian-specific: no CVE-Ids: CAN-2004-0597 CAN-2004-0598 CAN-2004-0599 CAN-2004-0768 Package: libpng Distribution: stable Architecture: any Binary: libpng2-dev, libpng2 Version: 1.0.12-3.woody.7 Package: libpng3 Distribution: stable Architecture: any Binary: libpng-dev, libpng3 Version: 1.2.1-1.1.woody.7 This can be easily distributed, parsed and compared to the package status database to determine which installed packages must be upgraded, and can raise an alert if required. I can script the generation of a MR-DSA from existing data, especially the DSA itself. Before I do: has anyone already done anything like this with DSAs, and would anyone be interested in using the resulting mechanism? Joshua. -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgpD9vIwzT60X.pgp Description: signature
Re: new tool - apt-method-https
On Sat, Jul 17, 2004 at 02:25:59PM +0200, Bernhard R. Link wrote: * Joshua Goodall [EMAIL PROTECTED] [040717 04:40]: I've developed a simple HTTPS method for APT using Perl's LWP libraries. Unlike all the other implementations I've seen so far, it doesn't replace the existing APT package; it just adds a new method. Support for client certificates is included. Please try it and give feedback! More info, including lines for sources.list(5), at http://www.roughtrade.net/linux/ Is there a reason the package depends on apt? A shortage of clear thinking on my part. I've changed the Depends: to the Enhances: it should have been. - Joshua. -- Joshua Goodall as modern as tomorrow afternoon [EMAIL PROTECTED] - FW109 pgpFmm2o6lpOj.pgp Description: PGP signature
new tool - apt-method-https
Hello all, I've developed a simple HTTPS method for APT using Perl's LWP libraries. Unlike all the other implementations I've seen so far, it doesn't replace the existing APT package; it just adds a new method. Support for client certificates is included. Please try it and give feedback! More info, including lines for sources.list(5), at http://www.roughtrade.net/linux/ Joshua -- Joshua Goodall as modern as tomorrow afternoon [EMAIL PROTECTED] - FW109 pgpG7u24u3FEQ.pgp Description: PGP signature
Re: BF kernels (was: [DSA 479-2] New Linux 2.4.18 packages fix local root exploit (i386))
On Thu, 15 Apr 2004 07:56 pm, Tim Nicholas wrote: If I recall correctly it is assumed that users will not run on the boot floppy kernels after the initial system installation. They are expected to install a more appropriate kernel after finishing the install. As such there will be no patch for the boot floppy kernel. I disagree with the generalisation. Let me tell you two little tales. 1. A few weeks ago I was building a new cluster of our servers. We operate a networked system that runs from its own network range, albeit behind a firewall. Within a few seconds of the network route being announced to the Internet, the entire range was neatly and efficiently portscanned on a range of commonly vulnerable ports. Adjacent netblocks were not scanned. i.e. someone was watching the new network range come up. In other words, people are ready to pounce, and that short gap of time after server installation and before installing patched code cannot be considered safe. Quite the opposite. 2. I have seen highly experienced, capable, intelligent, diligent, hardworking sysadmins accidently leave a bf kernel running. It happens. In our environment, it's usually noticed within a day. The specifics of DSA479 notwithstanding; either of these would motivate me to agree with Michelle that bootfloppies should be updated, too. (I roll our own kernel and installation CDs here, and we use updated custom packages in the debootstrap kit, so we don't have the same exposure.) - Joshua. -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgp0.pgp Description: signature
Re: BF kernels (was: [DSA 479-2] New Linux 2.4.18 packages fix local root exploit (i386))
On Thu, 15 Apr 2004 07:56 pm, Tim Nicholas wrote: If I recall correctly it is assumed that users will not run on the boot floppy kernels after the initial system installation. They are expected to install a more appropriate kernel after finishing the install. As such there will be no patch for the boot floppy kernel. I disagree with the generalisation. Let me tell you two little tales. 1. A few weeks ago I was building a new cluster of our servers. We operate a networked system that runs from its own network range, albeit behind a firewall. Within a few seconds of the network route being announced to the Internet, the entire range was neatly and efficiently portscanned on a range of commonly vulnerable ports. Adjacent netblocks were not scanned. i.e. someone was watching the new network range come up. In other words, people are ready to pounce, and that short gap of time after server installation and before installing patched code cannot be considered safe. Quite the opposite. 2. I have seen highly experienced, capable, intelligent, diligent, hardworking sysadmins accidently leave a bf kernel running. It happens. In our environment, it's usually noticed within a day. The specifics of DSA479 notwithstanding; either of these would motivate me to agree with Michelle that bootfloppies should be updated, too. (I roll our own kernel and installation CDs here, and we use updated custom packages in the debootstrap kit, so we don't have the same exposure.) - Joshua. -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgpWr70J6zTZA.pgp Description: signature
Possibly compromised ElGamal keys [was: Re: Time for apt-secure?]
On Thursday 27 November 2003 17:53, Camillo Srs wrote: Hi, As far as I can tell, apt-secure would have protected against any compromise of the archives in this hacking incident. That is, provided that the developers keep their private keys secure. Unfortunately, 32 keys on the current keyring use possibly compromisable ElGamal keys or subkeys, according to http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000276.html Those affected, and the project's keyring master/mistress, may wish to consider revocations. - Joshua. -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgp0.pgp Description: signature
Possibly compromised ElGamal keys [was: Re: Time for apt-secure?]
On Thursday 27 November 2003 17:53, Camillo Särs wrote: Hi, As far as I can tell, apt-secure would have protected against any compromise of the archives in this hacking incident. That is, provided that the developers keep their private keys secure. Unfortunately, 32 keys on the current keyring use possibly compromisable ElGamal keys or subkeys, according to http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000276.html Those affected, and the project's keyring master/mistress, may wish to consider revocations. - Joshua. -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgpzKF61Ocmct.pgp Description: signature
Re: No substitutions occuring in issue.net
On Sun, Oct 12, 2003 at 03:05:30PM +0100, Dale Amon wrote: I noticed some months ago that my issue.net file is broken, ie an ssh connection shows the tokens unsubstituted. Console connections that use /etc/issue look fine. openssh doesn't do banner substitutions. Look at the code path; it just goes: read file, write string. - Joshua signature.asc Description: Digital signature
Re: No substitutions occuring in issue.net
On Sun, Oct 12, 2003 at 03:05:30PM +0100, Dale Amon wrote: I noticed some months ago that my issue.net file is broken, ie an ssh connection shows the tokens unsubstituted. Console connections that use /etc/issue look fine. openssh doesn't do banner substitutions. Look at the code path; it just goes: read file, write string. - Joshua signature.asc Description: Digital signature
Re: execute application from webinterface
On Tuesday 02 September 2003 15:44, Ryan Nowakowski wrote: On Tue, Sep 02, 2003 at 01:38:24AM +0200, Christopher Taylor wrote: Jens Gutzeit wrote: On Monday 01 September 2003 21:53, mario ohnewald wrote: What is the securest way of starting a application, like ping, from a webinterface as a diffrent user. what's wrong with making the program suid-to-some-other-user (not root) and then just executing it? I reallize this doesn't work for ping, which is suid-to-root anyway. Another option is to use the Net::Ping perl module instead of the ping command itself. A secure, privilege-separated way to code this would be to have a daemon (yes, it could be a Perl daemon) that pings, rather than escalating runtime script to root unnecessarily. It could listen on localhost, and with a very simple protocol you could even authenticate with a shared secret. It runs as root, and pings on behalf of a simple protocol-speaking .php or .cgi. The privilege separation model seems smiled upon by many secure software designers. OpenSSH is one example of a production-grade implementation. J -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgp0.pgp Description: signature
Re: execute application from webinterface
On Tuesday 02 September 2003 15:44, Ryan Nowakowski wrote: On Tue, Sep 02, 2003 at 01:38:24AM +0200, Christopher Taylor wrote: Jens Gutzeit wrote: On Monday 01 September 2003 21:53, mario ohnewald wrote: What is the securest way of starting a application, like ping, from a webinterface as a diffrent user. what's wrong with making the program suid-to-some-other-user (not root) and then just executing it? I reallize this doesn't work for ping, which is suid-to-root anyway. Another option is to use the Net::Ping perl module instead of the ping command itself. A secure, privilege-separated way to code this would be to have a daemon (yes, it could be a Perl daemon) that pings, rather than escalating runtime script to root unnecessarily. It could listen on localhost, and with a very simple protocol you could even authenticate with a shared secret. It runs as root, and pings on behalf of a simple protocol-speaking .php or .cgi. The privilege separation model seems smiled upon by many secure software designers. OpenSSH is one example of a production-grade implementation. J -- Joshua Goodall [EMAIL PROTECTED] Solutions Architect / Principal Security Architect myinternet Limited. pgpil2cFb80kX.pgp Description: signature
Re: Injectso to help with libc upgrades?
On Thu, 1 May 2003 03:07 am, Drew Scott Daniels wrote: http://packetstorm.linuxsecurity.com/filedesc/injectso-0.2.1.tar.html describes injectso, a tool that can be used to inject shared libraries into running processes on Linux (x86/IA32 and Sparc) Maybe I misunderstand, but might it not be also possible to use this to inject replacements for shared libraries too? I don't think I'd want to leave such a tool lying around on my production servers :} More debianish would be some kind of additional dependency analyser that would restart afflicated daemons on your behalf. J pgp2zUVeXS32a.pgp Description: signature
Re: ssh authentication configuration?
Stephen, On Tue, May 28, 2002 at 05:51:02PM -0700, Stephen Johnson wrote: Hello, i'm confused on a couple variables in the sshd_config file, i have a client that's using that 'other os' and has an ssh client that he likes. however, he wanted me to secure the server as much as possible, i've always disabled clear text passwords(PasswordAuthentication no), and turn on pam auth (PAMAuthenticationViaKbdInt yes). That's always worked fine for me as i'm using debian linux, and i don't actually know why i do it other than in the conf file debian adds a comment above telling me to do so, so i do. Well, my clients ssh client app doesn't seem to be able to handle pam auth, so when i disable clear text passes it won't let him in, even though i can get in with his account from my ssh client. i guess what i'm asking is, How much of a security risk is using regular auth versus Pam?. I'll assume you're using openssh version 3.x that's in the debian/testing distribution. The password will still be sent in the clear; there is a difference in the way the server handles it (that is, it palms off to PAM the responsibility of letting you in) and a difference in the way the client negotiates (iirc it's nonfunctional if the client doesn't request keyboard-interactive negotiation). However, if you use PAM auth, then the login process will also pass through PAM's session and account elements; if you have defined any strict login restrictions there, then PasswordAuthentication will bypass them. This may or may not be an issue for you, but otherwise, PasswordAuthentication has equivalent security. Personally I recommend neither and tell everyone to prefer keys and one-time passwords, but that's another story :) Joshua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh authentication configuration?
Stephen, On Tue, May 28, 2002 at 05:51:02PM -0700, Stephen Johnson wrote: Hello, i'm confused on a couple variables in the sshd_config file, i have a client that's using that 'other os' and has an ssh client that he likes. however, he wanted me to secure the server as much as possible, i've always disabled clear text passwords(PasswordAuthentication no), and turn on pam auth (PAMAuthenticationViaKbdInt yes). That's always worked fine for me as i'm using debian linux, and i don't actually know why i do it other than in the conf file debian adds a comment above telling me to do so, so i do. Well, my clients ssh client app doesn't seem to be able to handle pam auth, so when i disable clear text passes it won't let him in, even though i can get in with his account from my ssh client. i guess what i'm asking is, How much of a security risk is using regular auth versus Pam?. I'll assume you're using openssh version 3.x that's in the debian/testing distribution. The password will still be sent in the clear; there is a difference in the way the server handles it (that is, it palms off to PAM the responsibility of letting you in) and a difference in the way the client negotiates (iirc it's nonfunctional if the client doesn't request keyboard-interactive negotiation). However, if you use PAM auth, then the login process will also pass through PAM's session and account elements; if you have defined any strict login restrictions there, then PasswordAuthentication will bypass them. This may or may not be an issue for you, but otherwise, PasswordAuthentication has equivalent security. Personally I recommend neither and tell everyone to prefer keys and one-time passwords, but that's another story :) Joshua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
That is a fair point but addressable with post-editing checks in the wrapper. Of course, one is exceedingly vulnerable to race conditions if one is not very careful about what is read and when. You don't have to use vi; there are dumber editors in the world. Maybe you should just have some programmatic (i.e. commandline, not full-screen) editing program for aliases that's callable from sudo. However the whole idea fills me with worry; /etc/aliases IS quite a critical file and I'm certain that specific attacks could be engineered against you if write access was obtained. Why not just have users make their changes and mail a diff to the sysadmin for approval :) J p.s. failing that, investigate LIDS; but that's a different ball game. On Fri, Nov 30, 2001 at 12:23:14PM +0100, Christoph Ulrich Scholler wrote: hi, maybe i misunderstand the intention here, but isn't it pointless to restrict privileges of the editing process of /etc/aliases if you could just as well change root's alias to a program that's run whenever root receives email and, e. g., puts one's most favourite /etc/passwd in place of the original? regards, uLI On Thu, Nov 29, 2001 at 02:45:08PM -0800 or thereabouts, William R Ward wrote: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
That is a fair point but addressable with post-editing checks in the wrapper. Of course, one is exceedingly vulnerable to race conditions if one is not very careful about what is read and when. You don't have to use vi; there are dumber editors in the world. Maybe you should just have some programmatic (i.e. commandline, not full-screen) editing program for aliases that's callable from sudo. However the whole idea fills me with worry; /etc/aliases IS quite a critical file and I'm certain that specific attacks could be engineered against you if write access was obtained. Why not just have users make their changes and mail a diff to the sysadmin for approval :) J p.s. failing that, investigate LIDS; but that's a different ball game. On Fri, Nov 30, 2001 at 12:23:14PM +0100, Christoph Ulrich Scholler wrote: hi, maybe i misunderstand the intention here, but isn't it pointless to restrict privileges of the editing process of /etc/aliases if you could just as well change root's alias to a program that's run whenever root receives email and, e. g., puts one's most favourite /etc/passwd in place of the original? regards, uLI On Thu, Nov 29, 2001 at 02:45:08PM -0800 or thereabouts, William R Ward wrote: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
