Re: forming a security team for testing
On Thu, Oct 28, 2004 at 05:43:55PM -0400, Joey Hess wrote: > Current list of security problems apparently unfixed in sarge: kernel-image-2.6.8-s390, CAN-2004-0887 Bastian -- War isn't a good life, but it's life. -- Kirk, "A Private Little War", stardate 4211.8 signature.asc Description: Digital signature
Re: forming a security team for testing
hi joey On Thu, 28 Oct 2004, Joey Hess wrote: > I've added a CVE/list also, with about 80 CVE's per year to add to the > things to check. We've only got 130 more CAN's to check for 2004, plus > the CVE's, and then we can start on 2003. > > Current list of security problems apparently unfixed in sarge: > > postgresql 7.4.6-1 needed, have 7.4.5-3 for CAN-2004-0977 > perl (unfixed; bug #278404) for CAN-2004-0976 > openssl (unfixed; bug #278260) for CAN-2004-0975 .. > apache2 2.0.53 needed, have 2.0.52-1 for CAN-2004-0885 > kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for CAN-2004-0746 was this list created/checked by a acript that it detected "have" and "needed" ?? - "have" can be easy .. may ways to get that info ( dpkg ) - "needed" can tricky by parsing the SA or originating author's site - next step is to give that script the option to upgrade only the selected package for the user's PC ?? - d/l and install the "needed" upgrades based on what packages was previusly installed on the users page - web page based - nah .. too much work for the user to know which ones to apply ? - maybe a new option "dpkg security-check" and "dpkg security-upgrade" is all that is needed, since the rest of the infastructure is already in place thanx alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forming a security team for testing
I wrote: > - Edit the CAN/list file and claim a range of CANs to check. Note that >CANs that have already been checked as part of the DSA checks are so >marked. Commit the file. I've added a CVE/list also, with about 80 CVE's per year to add to the things to check. We've only got 130 more CAN's to check for 2004, plus the CVE's, and then we can start on 2003. Current list of security problems apparently unfixed in sarge: postgresql 7.4.6-1 needed, have 7.4.5-3 for CAN-2004-0977 perl (unfixed; bug #278404) for CAN-2004-0976 openssl (unfixed; bug #278260) for CAN-2004-0975 netatalk (unfixed; bug #278396) for CAN-2004-0974 kbr5 (unfixed; bug #278271; not shipped in binary package) for CAN-2004-0971 arla (unfixed; bug #278273) for CAN-2004-0971 groff 1.18.1.1-2 needed, have 1.18.1.1-1 for CAN-2004-0969 libc6 (unfixed; bug #278278) for CAN-2004-0968 gs-common (unfixed; bug #278282) for CAN-2004-0967 gettext 0.14.1-6 needed, have 0.14.1-5 for CAN-2004-0966 mozilla-firefox 0.10.1+1.0PR needed, have 0.9.3-5 for CAN-2004-0909 mozilla-firefox 0.10.1+1.0PR needed, have 0.9.3-5 for CAN-2004-0908 mozilla-firefox 0.10.1+1.0PR needed, have 0.9.3-5 for CAN-2004-0906 mozilla-firefox 0.10.1+1.0PR needed, have 0.9.3-5 for CAN-2004-0905 mozilla-firefox 0.10.1+1.0PR needed, have 0.9.3-5 for CAN-2004-0904 mozilla-firefox 0.10.1+1.0PR needed, have 0.9.3-5 for CAN-2004-0903 mozilla-firefox 0.10.1+1.0PR needed, have 0.9.3-5 for CAN-2004-0902 apache2 2.0.53 needed, have 2.0.52-1 for CAN-2004-0885 kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for CAN-2004-0746 konqueror 4:3.2.3-1.sarge.1 needed, have 4:3.2.2-1 for CAN-2004-0721 kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for CAN-2004-0721 kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for CAN-2004-0690 gnats (unfixed; bug #278577) for CAN-2004-0623 qla2x00-source (unfixed; bug #27870) for CAN-2004-0587 overkill (unfixed; bug #278709) for CAN-2004-0238 cabextract 1.1-1 needed, have 1.0-1 for DSA-574-1 kpdf (unfixed; bug #278173) for DSA-573-1 gpdf 2.8.0-1 needed, have 2.8.0-0.1 for DSA-573-1 libpng3 1.2.5.0-9 needed, have 1.2.5.0-8 for DSA-571-1 kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for DSA-539 Current number of team members: 7 There's a mailing list on alioth that's supposed to get svn commit messages, but for some reason only mine currently seem to be getting through. I'm pondering whether to set up a list for the team too, or keep using this one. -- see shy jo signature.asc Description: Digital signature
Re: forming a security team for testing
Hi, El mié, 27-10-2004 a las 23:33, Joey Hess escribió: > - Provide timely security updates for testing, with fixes being made >available no more than four days after a DSA is released. > - Work with maintainers to include security fixes from unstable >that do not have DSAs. > - Maintain a public database and statistics about the current state of >security in testing. > > Exactly how we would handle doing security updates for testing will have to > be decided by the team. We will probably want to release gpg signed DTSA > (Debian Testing Security Advisories) to a mailing list and web site. It > seems likely that we could use the testing-proposed-updates queue to build > updates, if it gets set up for all arches and continues to work after the > sarge release. For tracking issues, we may need to come up with our own > system, or we may be able to use the BTS, it if gets the promised version > tracking support added to it. We might want to set up our own security > repository separate from testing, or not. I'm working on a project that aims to bring as most high security features it can to Debian (Sarge), Debian Hardened/Hardened Debian [1]. We have a lot of work done, but currently there are no final decisions about what Debian people want to do with it (also i think that this must change in the way of start getting in the rid with it and minimal time wasting). I hope i would be proud to give my two cents in anything you want, most in special dpatches and other suggestions. [1]: http://wiki.debian-hardened.org & http://www.debian-hardened.org Cheers, -- Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]> signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: forming a security team for testing
Kim wrote: > You write: " - Go through your claimed CANs and check changelogs, > advisories, do >testing, whatever is needed to satisfy yourself whether sarge is >vulnerable or not, and record your findings in the CANs file. >Note that the file is read by checklist.pl, so follow the simple file >format." > > I am sorry if I have misunderstood anything but "whatever is needed to > satisfy yourself" Since this is a personal matter isn't there chances that a > person may miss important issues? I rather surgest a clear program of checks > that at least must be done in order to avoid problems. You could as well suggest some formal system for the (stable) security team to use to decide whether a given advisory applies to Debian. AFAIK they don't have such a thing, they rely on their members' skills and good sense. This is a balance that the people doing the checking will have to draw for themselves. I don't have time to actually try to exploit 2 thousand security holes, and even an attempt to exploit a security hole can often fail. And the lists we're checking against are not complete. On the other hand, I _know_ that the level of checking I'm doing of CAN's -- which mostly amounts to changelog and advisory reading, some source checking and occasionaly pinging a maintainer on a hard issue -- is worthwhile, because I've found and filed nearly a dozen security bug reports in the past few days based on it, and found a further dozen or so other holes whose fixes have not yet made it to sarge. -- see shy jo signature.asc Description: Digital signature
Re: forming a security team for testing
Kim wrote: Dear Joey Hess Great work! You write: " - Go through your claimed CANs and check changelogs, advisories, do testing, whatever is needed to satisfy yourself whether sarge is vulnerable or not, and record your findings in the CANs file. Note that the file is read by checklist.pl, so follow the simple file format." I am sorry if I have misunderstood anything but "whatever is needed to satisfy yourself" Since this is a personal matter isn't there chances that a person may miss important issues? I rather surgest a clear program of checks that at least must be done in order to avoid problems. Kim Seems clear to me. When you are looking at an identified issue (from the Mitre database, an older DSA, or from 'somewhere') you need to check if it is fixed in testing. You either prove to yourself that it is fixed, or not. False positivies seem less likely, as to prove that it is fixed you would need to read something like a changelog that says 'fixes so and so security bug', or inspect the code that is involved and see for yourself if it is still vulnerable. False negatives don't seem like such a problem, as someone will eventually say "Hey, that really has been fixed, even though the Debian Testing Security team said it wasn't". Geoff Crompton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forming a security team for testing
Alvin Oga wrote: hi ya On Thu, 28 Oct 2004, Kim wrote: I am sorry if I have misunderstood anything but "whatever is needed to satisfy yourself" Since this is a personal matter isn't there chances that a person may miss important issues? I rather surgest a clear program of checks that at least must be done in order to avoid problems. that's the tricky part eveybody will want different levels of security Sounds like people have started getting a different idea than what Joey initially proposed. I believe he suggested using external security databases (such as the Mitre list, and previous DSA's) and verifying that those identified issues are not present in testing packages. I'm sure he also ment that security issues identified through other processes (other people doing audits) would be in scope for this team to fix. I don't think he ment that this team would start auditing all Debian packages, nor proposing policy about security issues to try and satisfy everybodies different ideas on security. I'm sure that might occur to some degree as an aside, but I doubt that is the main focus of what Joey is proposing. Geoff Crompton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forming a security team for testing
hi ya On Thu, 28 Oct 2004, Kim wrote: > I am sorry if I have misunderstood anything but "whatever is needed to > satisfy yourself" Since this is a personal matter isn't there chances that a > person may miss important issues? I rather surgest a clear program of checks > that at least must be done in order to avoid problems. that's the tricky part eveybody will want different levels of security there should be minimum basic security ( eg required updates ) there should be application based updates ( apache/exim/dns/fw/etc ) there should be kernel patches there should be tcp wrappers and sshd config there should be ids and what triggers "wake up now" vs "false alarms" ... on and on ... we'd probably will need multiple "security checking" programs harder or simpler issue will be: - how to test to see the apps is patched or not susceptible to the latest exploit in that package - latest/greatest may not necessarily be "more secure" - another major issue is "patch now" vs patch later after the project is released and than change to new environment, changing things in the dmiddle of a development cycle is no fun - all security testing/qa/release cycles should be "automated" - we can all run the security scripts on our own machines and see if it dies or what it finds - it'd also be nice if the "security checking" can be distro nuetral ( same files, same apps, same patches, etc ) c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forming a security team for testing
Dear Joey Hess Great work! You write: " - Go through your claimed CANs and check changelogs, advisories, do testing, whatever is needed to satisfy yourself whether sarge is vulnerable or not, and record your findings in the CANs file. Note that the file is read by checklist.pl, so follow the simple file format." I am sorry if I have misunderstood anything but "whatever is needed to satisfy yourself" Since this is a personal matter isn't there chances that a person may miss important issues? I rather surgest a clear program of checks that at least must be done in order to avoid problems. Kim - Original Message - From: "Joey Hess" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Matt Zimmerman" <[EMAIL PROTECTED]>; "Bdale Garbee" <[EMAIL PROTECTED]>; "Chris Halls" <[EMAIL PROTECTED]>; "Martin Schulze" <[EMAIL PROTECTED]>; "Andreas Mueller" <[EMAIL PROTECTED]>; "Petter Reinholdtsen" <[EMAIL PROTECTED]>; "Martin Michlmayr" <[EMAIL PROTECTED]>; "Andreas Barth" <[EMAIL PROTECTED]>; "Ernesto Hernandez-Novich" <[EMAIL PROTECTED]>; "Finn-Arne Johansen" <[EMAIL PROTECTED]>; "Djoumé SALVETTI" <[EMAIL PROTECTED]>; "Steinar H. Gunderson" <[EMAIL PROTECTED]>; "Andres Salomon" <[EMAIL PROTECTED]> Sent: Wednesday, October 27, 2004 11:33 PM Subject: forming a security team for testing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
forming a security team for testing
I've been talking to people about the idea of forming a security team for the testing distribution for several months, and there seems to be enough interest in improving testing's security to make such a team a reality. Most of the people in the CC list have indicated interest in a testing security team; we're interested in improving testing's security for diverse reasons including: use of testing at work; shipping products based on testing; hoping to base derived Deban distributions on testing rather than stable; wanting testing to be a viable choice for Debian users; and so on. The team will consist of Debian developers and possibly others. Unless a member of the Debian security team joins the Debian testing security team, none of us will have any privileged information about future security announcements. Anyone with interest and experience with security issues is welcome to join the team. To talk about how I think this team would work on testing's security, I need to talk about two distinct stages, before the sarge release, and after. Right now we're at a point in the sarge release cycle where most of the focus of a testing security team needs to be on identifying and fixing sarge's security problems and getting it ready for release. This means checking to make sure that security problems that have already been fixed in unstable and stable do not continue to affect testing, as well as dealing with new holes. I don't think Debian has really invested much effort into this in past releases, but if we want sarge to be a secure release from the beginning, it's important to do it. If we do that work now, then after sarge is released, we will only need to worry about keeping track of new security holes and releasing security advisories. Work before sarge's release: --- Some work on checking sarge for old security issues has already been done. With help from some of the people in the CC list, I coordinated a scan of every DSA since woody's release and we checked all 450 DSAs to see if fixes for those security holes had reached testing. Suprisingly, we found some security holes that had not gotten fixed in testing in a year or more, though those were the exceptions. I've continued to do this checking as each new DSA is released, as well as filing bugs, working with the security team and Release Managers, and doing a few NMUs to get the fixes in. The current list of unfixed DSAs sarge is: [EMAIL PROTECTED]:~/sarge-checks>./checklist.pl DSA/list kpdf (unfixed; bug #278173) for DSA-573-1 gpdf 2.8.0-1 needed, have 2.8.0-0.1 for DSA-573-1 libpng3 1.2.5.0-9 needed, have 1.2.5.0-8 for DSA-571-1 kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for DSA-539 But checking DSAs is not a complete check of known security issues that might still be lurking in sarge. To do a really complete scan means looking through old non-DSA advisories as far back as is reasonable or doable. I think doing this scan and the following up on it to fix things would be a good first step for the team, and a way to begin figuring out how the team will work together. Mitre has a fairly comprehensive list of security problems in their list of CAN numbers[1]. There have been about 1000 CANs allocated this year, some of them are not released yet, some were covered by the DSAs and I've checked a few hundred, so there are about 400 left. I think 4 or 5 people could check these in a reasonable time period, and maybe do 2003 as well. So if you're interested in checking some of the CANs to see if they are fixed in sarge, here's what to do: - Sign up for an alioth account if you don't have one. - Send me your userid to be added to the secure-testing project on alioth. - svn co svn+ssh://svn.debian.org/svn/secure-testing/sarge-checks - Edit the CAN/list file and claim a range of CANs to check. Note that CANs that have already been checked as part of the DSA checks are so marked. Commit the file. - Go through your claimed CANs and check changelogs, advisories, do testing, whatever is needed to satisfy yourself whether sarge is vulnerable or not, and record your findings in the CANs file. Note that the file is read by checklist.pl, so follow the simple file format. - If it's also not fixed in sid, then be sure to file a RC bug; if it's fixed in sid but not in sarge, be sure to record it as a critical issue on the Release Managers' sarge issue tracker here: http://www.wolffelaar.nl/~sarge/ Do other followup as appropriate to get the fix into sarge. Along with looking for old unfixed holes in sarge and working on getting them fixed, we should also keep up-to-date with tracking new holes as they're announced. Work after sarge's release: -- By the time sarge releases, I hope to already have a team that has worked together on getting sarge secure, and we'll have a testing distribution with no old security holes in it. This woul
