Re: PPA security (was: Debian mirrors and MITM)
Hans-Christoph Steiner wrote: This could be approached another way. There could be scripts in the packaging tools that mark a package if it does not run anything in any of the scripts that does not come from the packaging tools. I think many many packages would qualify here, most packages do not touch the pre/post scripts, so the ones that are included are generated by debhelper or whatever. Then you could see whether a package is requesting to run its own scripts as root, and make the call there. A package that does not add anything to those scripts would be pretty safe to install, at least. There is a lot of code that is run by maintainer scripts that currently has no reason to worry about the security of its inputs, which are provided by files in the package. For this to work, it would all need to be made secure. Retroactively adding such a security requirment is a good way to end up playing security wack-a-mole for many years thereafter. -- see shy jo signature.asc Description: Digital signature
Re: Debian mirrors and MITM
Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. -- see shy jo signature.asc Description: Digital signature
Constantly Usable Testing BoF @ DebConf10
I'd like to invite any security team members who are attending DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30. http://penta.debconf.org/dc10_schedule/events/681.en.html The purpose of the BoF is to finally explore whether it would make sense to implement the Constantly Usable Testing idea[1], ways to do it, and get feedback and advice from teams that could be affected by it. Way back when, the secure-testing infrastructure was the most important prerequisite for thinking about CUT in the first place. Since all I do for that now is run a cron job :) I am left with questions like these: * Is testing getting security updates frequently enough compared to stable to be able to be promoted to users as secure? * How much extra work would be involved in supporting periodic snapshots of testing? * How could having CUT *help* the security team, perhaps by encouraging developers to work faster on security issues in unstable/testing? -- see shy jo [1] http://kitenet.net/~joey/code/debian/cut signature.asc Description: Digital signature
Re: gmonstart / jvregisterclasses in tons of binaries with commands,malware?
whereislibertyandjust...@safe-mail.net wrote: __gmon_start__ A minute with a search engine will tell you this symbol is included in the standard glibc, and is a hook into early program runtime provided by sysdeps/generic/initfini.c _Jv_RegisterClasses This is part of GCC's libgcc library, and is defined in the crtstuff.c file. http://www.google.com/codesearch/ is an easy way to find the code where symbols you are interested in originate. These strings are not alone by themselves in the binaries they follow with commands with a @ mark before each command. If you're referring to things like these: setrli...@glibc_2.0 msg...@glibc_2.0 That is library symbol versioning, a feature of linux's linker, most often used by glibc. http://people.redhat.com/drepper/symbol-versioning -- see shy jo signature.asc Description: Digital signature
Re: DSAs really missing from the tracker
Michael S. Gilbert wrote: Joey, if you send me the existing Mitre scripts, I will take a look at modifying them for NVD. See bin/update in secure-testing svn. -- see shy jo signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Florian Weimer wrote: On the hand, if you don't build a network of your own, and your ISP properly filters their Internet connection and their customer interfaces to stop source address spoofing, it's not possible forge DNS traffic which claims to come from the ISP resolver. (Since the addresses involved are theirs, they can actually do it--globally, on the whole Internet, it's much more difficult.) IIRC Dan Kaminsky has been suggesting using opendns, which has fixed servers, if your ISPs server is not fixed. Won't using a third-party DNS server defeat any filtering your ISP does on their network, and allow the stub resolver to be spoofed? -- see shy jo signature.asc Description: Digital signature
Re: Microsoft-IIS/6.0 serves up Debian... WTF!
Jim Popovitch wrote: Here's my issue, please correct me if I am wrong. .debs and sigs both exist on the same server. If the Windows box/network is compromised, then the sigs and debs can be modified and who would know? The security provided by a gpg signature is the difficulty in forging the signature, not the server that serves it. http://wiki.debian.org/SecureApt -- see shy jo signature.asc Description: Digital signature
Re: DSA-1571 and GSSAPI
Juha Jäykkä wrote: Just count how many times you've used GPG over one of the weak links... Zero! Zero gpg invocations over network links! -- see shy jo, with apologies to countmail signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
Noah Meyerhans wrote: We mention all the binary packages in the advisory because they're the versions that are going to be installed by apt* and people are going to want checksums, file sizes, etc. .. For no good reason, since apt checks all those things for you. That information is a confusing relic, and could be removed from the advisory templates. -- see shy jo signature.asc Description: Digital signature
Re: secure installation
Javier Fernández-Sanguino Peña wrote: Actually, I've just found that there is actually an update-notifier for KDE, it's provided by adept (a package management interface similar to synaptic). Try installing adept-notifier. Perhaps it's time to revisit droppimg kpackage from kde-desktop and adding adept. The kde task could use more people using it and making decisions like this about its contents. -- see shy jo signature.asc Description: Digital signature
Re: Time to replace MD5?
Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? I don't understand why DSAs for etch include md5sums and manual upgrade instructions at all. Apt can verify the checksum and gpg signature and handle the upgrade after all, and probably more securely than the average user following the manual instructions. It may have made sense before we had signed Release files, (or perhaps before we had apt :-), but it feels obsolete now. Note that DTSAs already only include apt upgrade instructions. -- see shy jo signature.asc Description: Digital signature
Re: Time to replace MD5?
Bernd Eckenfels wrote: Because open source is all about choice. So it's there because of a platitude? There might be admins using dpkg -i or security officers who build their local mirrors manually. Then why don't we include md5sums and wget commands for all packages in stable point release annoucements? Why not include them in major release announcements too? Or are these things somehow less all about choice? -- see shy jo signature.asc Description: Digital signature
Re: debian testing Packages.bz2 md5 sum mismatch
Clemens Schwaighofer wrote: today (2006/07/27) I found out that the Packages.bz2 md5sum for binary-i386 in the testing tree does not match the one in the Release file. You forgot to say what mirror you're using. I hope there is no serious issue goeing on Doubtful, probably just a failed archive sync. -- see shy jo signature.asc Description: Digital signature
Re: security support for kernel-image-2.4.27-2-XXX discontinued?
Mikko Rapeli wrote: Why isn't kernel-image-2.[4, 6]-[386, 686...] installed by the installer, since it is required for kernel security support? We didn't think to do that until too late for sarge. If this is just a sarge thing, could linux-image-2.6-[386...] be installed by default in etch? It is. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Loïc Minier wrote: On Fri, Mar 03, 2006, Joey Hess wrote: Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. It's a but in task installation then. If you mean a bug, no, I go out of my way to not install recommends, because Debian is still rife with long and useless recommends chains. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Philipp A. Hartmann wrote: But still it's only a Recommends. Therefore, rhythmbox needs to handle the absence og avahi-daemon gracefully, since you cannot rely on it's installation. For sake of plug-and-play and comfort, this might be even done in some kind of GUI message, which tells the user what to do, if he/she wants to access a feature, that requires the daemon's presence. If avahi is not running, rhythmbox prints this to std(something) on startup and/or when you enble sharing in its prefs: (rhythmbox:24998): Rhythmbox-WARNING **: Unable to start mDNS browsing (rhythmbox:24998): Rhythmbox-WARNING **: Unable to notify network of music sharing Otherwise it behaves fine. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Javier Fernández-Sanguino Peña wrote: - rhythmbox does not mention music sharing *at*all* in the package description. Even the GUI doesn't mention this (when starting it up for the first time) nor the documentation (in it's 'Introduction') Rhythmbox doesn't go broadcasting files over the network without being explcitly told to do so in the prefs. It does do mdns discovery of other music shares on the network automatically though. - a default GNOME install should *not* install a network service, even if that enabled new features to the users. Consequently, if rhythmbox is part of the GNOME task, it should not pull in ahavi-daemon automatically (a Recommends: is automatic for aptitude, not for apt-get, and aptitude is the tool we suggest in our Release Notes for upgrades) Does aptitude actually pull in new recommends when upgrading a package? IIRC it did not. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Loïc Minier wrote: I completely agree there are a number of broken recommends, but shouldn't we fix these? Yes, it's painful. :( I'd prefer not to break new installations in order to find them. This thread shows that pulling in recommends by default in aptitude is enough to expose problimatic recommends chains eventually. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Loïc Minier wrote: It would be overly complicated to handle the case of a Suggests instead of a Recommends correctly: even if the code was updated to handle both cases at run time, and would hide the relevant options when these are not available, the documentation would still point at unavailable features. And the popup mixing application level information with package level information would also be awful: You should install package foo to get this functionality. Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. -- see shy jo signature.asc Description: Digital signature
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh wrote: 3. The security team's work is helped by adding the CVE information to the proper changelog entry, to the point that they have requested everyone to do so. This requires editing past changelog entries quite often. I don't think that the security team has ever requested retoractive changing of changelogs for CVE entries. I find it hard to envision a scenario where that would be more useful to them than a note in the next release. I am quite sure that the testing security team has not asked for such retroactive changes, and that we don't need them. Of course we do appreciate it when maintainers put CVE information in changelogs, and we've asked them to do so. Although these days I think you'll more likely see the relevant bug in the BTS be usertagged with the CVE id before the package is even released. Once that tag is there, we're tracking the security issue and the changelog entry will only matter to users and other security researchers. -- see shy jo signature.asc Description: Digital signature
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh wrote: Found it. From: Martin Schulze [EMAIL PROTECTED], Message-ID: [EMAIL PROTECTED], and Message-ID: [EMAIL PROTECTED] at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282681 Please add this id to the proper changelog entry with the next upload. That's easily misinterpreted, although I won't try to guess which of us is doing so. One thing that this bug illustrates pretty well that is quite annoying when trying to determine what version of a package actually fixed a security hole, is new upstream releases that are listed in the changelog as fixing a particular CVE, when the hole was actually fixed in a previous debian revision of the old upstream version. That's a case where clarity is very useful in the changelog. (So is proper use of the new version tracking features of the BTS.) -- see shy jo signature.asc Description: Digital signature
bts usertags for CVE ids
In honor of CAN to CVE switchover day, I've written a program that will notice changes in the testing security teams's database of security issues, and uses this to set/unset usertags (with debian-security@lists.debian.org as the user) in the BTS. So for any CVE that we record as having a bug report, that bug report will be automatically usertagged with the CVE id. The program has imported all our existing (unfortunatly not complete for the whole history of the team) information about security bugs, so 520 bugs already have CVE usertags now. You can see some of them here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security;[EMAIL PROTECTED] (Or anywhere else in the BTS by adding ;[EMAIL PROTECTED] to the end of a URL.) The program also adds another tag, tracked for all bugs that have an entry in our list. This is to help in finding bugs that we're not tracking. Here for example is a view into the BTS of security bugs categorised[1] based on whether or not they are currently tracked by the testing security team: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security;[EMAIL PROTECTED];ordering=tracked Any changes should be reflected in the BTS within half an hour of the commit to our repository. Of course anyone can also add (or remove) CVE id usertags to bugs on their own if they want to. -- see shy jo [1] Using the following usercategory definition, if you're curious: user debian-security@lists.debian.org usercategory is-tracked [hidden] * Tracked or not [tag=] + tracked [tracked] + untracked [] usercategory tracked * is-tracked * status * severity * category signature.asc Description: Digital signature
Re: anonftpsync (was: security archive defective!?)
Andreas Barth wrote: That all the neccessary directories and symlinks are mirrored, including project/trace. Also, AFAIUI debmirror creates a much higher load on the server you're pulling from than anonftpsync (as debmirror opens lots of rsync-connections, whereas anonftpsync just does two). debmirror handles trace files properly and can use a single ftp connection. Or at least it did when I wrote it. -- see shy jo signature.asc Description: Digital signature
Re: Bad press related to (missing) Debian security
martin f krafft wrote: Not meaning to disspell it, but isn't this essentially a bug tracking system or ticket system done slightly differently? No, if it were a bug tracking system we could use the Debian BTS and not bother with it. It's a vulnerability/non vulnerability tracking system; we use it to not only track holes that affect testing, but just as importantly, holes that do not. It allows us to know that every security issue has been checked out by someone with no gaps (our historical checks of all security holes since woody found holes that were missed from being tracked in the BTS). Of course it works with the BTS, and once the BTS gets version tracking certain bits of it will become more automated. -- see shy jo signature.asc Description: Digital signature
Re: CAN-2005-0210, kernel netfilter dos memory leak
Geoff Crompton wrote: On http://merkel.debian.org/~joeyh/testing-security.html this CAN is listed, as waiting for a 2.4.27-9 to fix this issue. The securityfocus article says that this is a 2.6.8 issue. Does anyone know if a fix for this has made it into a 2.6.8 debian kernel? It's fixed in version 2.6.8-15 of the kernel. -- see shy jo signature.asc Description: Digital signature
Re: apache and CAN-2003-0020
Geoff Crompton wrote: CAN-2003-0020 is a vulnerability in apache that mentions how apache allows escape sequences into the error logs, which might exploit a terminal program viewing them. More detail is at http://www.securityfocus.com/bid/9930. The securityfocus page lists Debian as being vulnerable, and I can't find a DSA that corresponds to CAN-2003-0020. Does anyone know if Debian is vulnerable or fixed? CAN-2003-0020 - apache2 2.0.49 - apache 1.3.29.0.2-4 Above are the versions that contained the fixes, for unstable/testing. -- see shy jo signature.asc Description: Digital signature
Re: using sarge on production machines
Stefan Fritsch wrote: Updates that fix security issues usually have urgency=high and change faster to testing. However, you cannot trust this since new release critical bugs might still keep the new package from entering testing. New release critical bugs need not keep a security update from testing, unless the new release with the security update itself introduced more release critical bugs than it solved. If unrelated RC bugs are filed, the release team has the power to force a security fix into testing anyway. Dependency issues blocking a security update from reaching testing remains the main blocker for security updates reaching testing and probably will continue to do so until the autobuilders fully support testing. -- see shy jo signature.asc Description: Digital signature
Re: bind vulnerabilities
Geoff Crompton wrote: SecurityFocuse newsletter #286 lists some bind issues: http://www.securityfocus.com/bid/12364 CAN-2005-0033 This affected bind, but was fixed in version 8.4.6-1. Testing is still vulnerable. AFAIK it does not affect bind9. http://www.securityfocus.com/bid/12365 CAN-2005-0034 We dodged this one, it only affects bind9 9.3.0, and we have an earlier version. -- see shy jo signature.asc Description: Digital signature
Re: IDNA and security
Florian Weimer wrote: People are filing security bugs because of the homograph issue. But is this a real security problem? Do you think we should change our fonts so that 1, l and I (and O and 0, of course) are more different visually? That misses part of the point of the homograph issue, which is that besides characters that look confusingly alike, unicode contains charaters that are *identical*, except for being in a different code pages. See http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf Michael Stone wrote: Yes it does. Ecommerce security is founded on the idea that if the little padlock is lit up you're secure. That little padlock is based on the name. And if you have trusted that little padlock with anything important anytime recently without at least making sure you have reasonable insurance, you've not been paying attention. FWIW, I've filed the bugs I did on this issue at normal priority, because it was not at all clear to me that the bug meets the criteria for being release critical, since the actual bug is in the basic design of unicode domain names, in the lacking procedures of the CAs and registrars who do not check for homograph issues, and in the overall design of so-called ecommerce security. Any fixes in the packages can at best only be heuristics and workarounds, and will likely just lead to an escalating arms race if this problem is worth exploiting. -- see shy jo signature.asc Description: Digital signature
Re: woody kernel image
[EMAIL PROTECTED] wrote: I currently run Sarge on a few machines, but as I understand Debian policy, Sarge does not receive security updates. The only security updates I can expect are for Woody, so this makes Sarge unreliable for a production environment. Increasingly innaccurate; see http://merkel.debian.org/~joeyh/testing-security.html In the case of the recent kernel holes, IIRC[1] the 2.6 kernel is now fixed in sarge, while 2.4 is bring blocked out due to some other RC bugs (though I've been working to let it in anyway). I guess this is a good time for me to try to see if I can help the Debian Security Folks out if they need it. If you have the ability to work on verifying and patching security hole then you can certianly help the _Sarge_ security team. We're not yet able to offer complete security support for sarge due to a lack of some set up autobuilders for the t-p-u queue, but we are doing a lot of work and managing to get most security holes fixed in sarge ASAP. -- see shy jo [1] Over the atlantic and can't check. signature.asc Description: Digital signature
Re: [SECURITY] [DSA 643-1] New queue packages fix buffer overflows
Martin Schulze wrote: For the unstable distribution (sid) these problems have been fixed in version 1.30.1-5. A day later and unstable still has 1.30.1-4.2 and I see no 1.30.1-5 in incoming. Did the upload go missing? -- see shy jo signature.asc Description: Digital signature
Re: CAN-2005-0001, CAN-2004-1235, CAN-2004-1137, CAN-2004-1016, Georgi Guninski security advisory #72, 2004, grsecurity 2.1.0 release
Jan Lühr wrote: things seem to be in a rush right now, and I'm looking for a little overview. In the past 1-2 months several kernel exploits rushed through the news that might / can / probably will affect debian stable. However, I haven't seen any signle DSA regarding the following issues: Can you please give me an overview: Which problems do affected kernel-source-2,4.18? - If so, what is the current status of the according DSA? I'm afraid that I can only tell you the status of 2.6.8 and 2.4.27 in unstable/testing. AFAIK there have not been DSAs for any of these to fix stable, and I don't know which ones really affect stable. Probably most of them. Some of the information below may be incorrect, the kernel team knows better than I. CAN-2005-0001 Linux kernel i386 SMP page fault handler privilege escalation: http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt (I'm not runnig SMP ;) The kernel team are aware of it, I expect a fix will be uploaded soon for unstable. CAN-2004-1235 Linux kernel uselib() privilege elevation http://isec.pl/vulnerabilities/isec-0021-uselib.txt (Sounds scary PoC Code is included, seems to be discussed here) Fixed in kernel-source-2.6.8 2.6.9-5 and kernel-source-2.4.27 2.4.27-8 (which should be released today or so), and the kernel-image packages indirectly built from them. CAN-2004-1137 Linux kernel IGMP vulnerabilities (Sounds really scary. Are we effected? Debian Woody seems to be uneffected, but what about sarge / sid?) http://isec.pl/vulnerabilities/isec-0018-igmp.txt Fixed in kernel-source-2.4.27 2.4.27-7. CAN-2004-1016 Linux kernel scm_send local DoS http://isec.pl/vulnerabilities/isec-0019-scm.txt Also fixed in kernel-source-2.4.27 2.4.27-7. Georgi Guninski security advisory #72, 2004 Fun with the linux kernel (2.6,2.4) http://www.guninski.com/where_do_you_want_billg_to_go_today_2.html This is CAN-2004-1333 and was fixed in kernel-source-2.6.8 2.6.8-11. AFAIK 2.4 is not yet fixed. grsecurity 2.1.0 http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2005-01/0070.html gives on scary / FUD-ish view on the linux kernel. Without discussing their thesis in detail, are patches available? Is kernel-source-2.4.18 affected? I don't think CANs have yet been assigned for those holes. A few others you left out: CAN-2004-1337 Apparently only affects 2.6, we're not very vulnerable since the module is loaded by the initrd. Not yet fixed. CAN-2004-1335 Fixed in kernel-source-2.6.8. 2.4 is not fixed. CAN-2004-1234 Does not affect sarge since we have a kernel 2.4.25. CAN-2004-1191 Should not affect our 2.4 kernel since it was fixed in 2.4.27. Probably our 2.6.8 kernel is vulnerable. CAN-2004-1190 Could be SuSE specific, unclear and not enough info. CAN-2004-1151 My notes indicate that this was fixed in svn at some point, but I can't find the fix now. CAN-2004-1144 Amd64 specific, don't know if we're vulnerable. CAN-2004-1074 Fixed in kernel-source-2.6.8 2.6.8-11, kernel-source-2.4.27 2.4.27-7, and te binary packages uild from them. CAN-2004-1073 CAN-2004-1072 CAN-2004-1071 CAN-2004-1070 2.6.8 and 2.4.27 are not vulnerable to these. CAN-2004-1069 Only affects 2.6. Fixed in kernel-source-2.6.8 2.6.8-11. CAN-2004-1068 Fixed in kernel-source-2.4.27 2.4.27-7, kernel-source-2.6.8 2.6.8-11. CAN-2004-1058 AFAIK it's unfixed. CAN-2004-1056 Fixed in kernel-source-2.4.27 2.4.27-8 (not yet released), kernel-source-2.6.8 2.6.8-11. CAN-2004-1017 Unknown. CAN-2004-1016 Fixed in kernel-image-2.4.27-i386 2.4.27-7. CAN-2004-0949 Fixed in 2.4.27, but 2.6.8 may still be vulnerable. CAN-2004-0887 s390 specific. Fixed in linux-kernel-image-2.6.8-s390 2.6.8-3, kernel-source-2.6.8 2.6.8-10 CAN-2004-0883 Unknown. CAN-2004-0814 Fixed in kernel-source-2.6.8 2.6.8-8, kernel-source-2.4.27 2.4.27-7 CAN-2004-0813 Fixed in recent 2.6 and 2.4 kernels. CAN-2004-0685 Unknown. CAN-2004-0596 Unknown. CAN-2003-0465 May be unfixed in our 2.4.27 kernel on some arches (bug #280492) i386 and ppc32 are ok. 2.6 fixed. -- see shy jo, wondering when the kernel security silly season closes signature.asc Description: Digital signature
Re: CAN-2004-1018, CAN-2004-1019 fixed in php4 (4:4.3.10-1), no DSA?
Bob Tanner wrote: I see CAN-2004-1018, CAN-2004-1019 are fixed in php4 (4:4.3.10-1) which is in unstable. Wondering why I haven't seen a DSA for it yet. CAN-2004-1018 is a rejected CAN. CAN-2004-1019 is marked as reserved in mitre's database with no other info. Same for all the other CANs fixed in the new php4 releases, they're all rejected or reserved. Rather strange.. Anyway, I suppose the delay with the stable package has somthing to do with the advisory being released on Wednesday, and any of these CANs that are real holes needing to be backported to the old version of php4 in stable. -- see shy jo signature.asc Description: Digital signature
Re: [SECURITY] [DSA 609-1] New atari800 packages fix local root exploit
Martin Schulze wrote: For the stable distribution (woody) these problems have been fixed in version 1.2.2-1woody3. For the unstable distribution (sid) these problems will be fixed soon. Actually, according to http://marc.theaimsgroup.com/?l=bugtraqm=110149441815270w=2 upstream version 1.3.2 in sid/sarge is not vulnerable. -- see shy jo signature.asc Description: Digital signature
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
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
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: Why do system users have valid shells
Russell Coker wrote: We can start with bin, daemon, sys, and sync which are the least likely accounts to need a login shell. Er, the only known point of the sync user is to give it a login shell. sync:x:4:65534:sync:/bin:/bin/sync -- see shy jo signature.asc Description: Digital signature
Re: Why do system users have valid shells
Russell Coker wrote: We can start with bin, daemon, sys, and sync which are the least likely accounts to need a login shell. Er, the only known point of the sync user is to give it a login shell. sync:x:4:65534:sync:/bin:/bin/sync -- see shy jo signature.asc Description: Digital signature
Re: Debian + Verisign's .com/.net hijack
Arthur de Jong wrote: This will only work for a little while as a colleague of mine noted. This will block * IN A 64.94.110.11 but not * IN NS 64.94.110.11 which is a valid delegation. The 64.94.110.11 nameserver should then only return 64.94.110.11 for all requests for A records. Paul Vixie addressed just this possibility in [EMAIL PROTECTED] on the NANOG list. You can mark such a name server as bogus. Assuming that IP is routable at all; I have not seen a packet from 64.94.110.11 in over 24 hours. -- see shy jo pgp0.pgp Description: PGP signature
Re: Debian + Verisign's .com/.net hijack
Arthur de Jong wrote: This will only work for a little while as a colleague of mine noted. This will block * IN A 64.94.110.11 but not * IN NS 64.94.110.11 which is a valid delegation. The 64.94.110.11 nameserver should then only return 64.94.110.11 for all requests for A records. Paul Vixie addressed just this possibility in [EMAIL PROTECTED] on the NANOG list. You can mark such a name server as bogus. Assuming that IP is routable at all; I have not seen a packet from 64.94.110.11 in over 24 hours. -- see shy jo pgpV66eptaCgn.pgp Description: PGP signature
Re: Please clarifiy: kernel-sources / ptracebug / debian security announcenments
The security team has already released two DSA's on the ptrace issue. Those would be DSA 270 and DSA 276. Why they have not put priority on fixing it for the i386 architecture I do not know, but I do know that modifying the kernel in stable on i386 is a monstrous problem, as doing it right means you have to: - rebuild all the different kernel images - rebuild all the modules packages external to the kernel, which would get broken by the above rebuild - rebuild the boot floppies - rebuild the install CD's -- see shy jo, not a member of the security team pgpGAbvVbjkmT.pgp Description: PGP signature
Re: Please clarifiy: kernel-sources / ptracebug / debian security announcenments
Nils Juergens wrote: fixing it for the i386 architecture I do not know, but I do know that modifying the kernel in stable on i386 is a monstrous problem, as doing it right means you have to: - rebuild all the different kernel images - rebuild all the modules packages external to the kernel, which would get broken by the above rebuild - rebuild the boot floppies - rebuild the install CD's And that is not true for the architectures that _were_ patched? It's certianly less true of ie, s390. There are not a lot of third pary kernel modules for s390, for example, and if there are any, they're not needed during install like the pcmcia modules are. I also think that a patched 2.4.20-ptrace as replacement for 2.4.20 would have not much problems running external modules. Maybe if you got rather lucky and didn't inaverdently change anything else. -- see shy jo pgp8QUGT7ziSi.pgp Description: PGP signature
Re: FTP-SSL
Rick Moen wrote: sftp is really an odd beast, which is part of why it's used so little. If you can get mileage out of many features of ssh within it, you're doing better than anyone else I know of. sftp is of value if only because it lets you use lftp fish:// , so you get a kick-ass ftp client interface with ssh encrypted goodness in the backend. -- see shy jo msg08308/pgp0.pgp Description: PGP signature
Re: FTP-SSL
Rick Moen wrote: sftp is really an odd beast, which is part of why it's used so little. If you can get mileage out of many features of ssh within it, you're doing better than anyone else I know of. sftp is of value if only because it lets you use lftp fish:// , so you get a kick-ass ftp client interface with ssh encrypted goodness in the backend. -- see shy jo pgpLpBfP61WGt.pgp Description: PGP signature
Re: spam
Thomas Horsten wrote: Set your mail server up to filter all Korean mail (that is, if you don't have any friends or relatives in Korea). You might also want to make sure that you'll never be using any Debian packages maintained by any of our South Korean Debian developers before you do this. Developers tend to get annoyed if they try to help someone and have their mail blocked by some over-broad generalization (I know I would be..). -- see shy jo msg07680/pgp0.pgp Description: PGP signature
Re: spam
Thomas Horsten wrote: Set your mail server up to filter all Korean mail (that is, if you don't have any friends or relatives in Korea). You might also want to make sure that you'll never be using any Debian packages maintained by any of our South Korean Debian developers before you do this. Developers tend to get annoyed if they try to help someone and have their mail blocked by some over-broad generalization (I know I would be..). -- see shy jo pgpRAow1GeC31.pgp Description: PGP signature
Re: wtmp rest to zero bytes
Matt Zimmerman wrote: On Thu, Nov 07, 2002 at 08:57:26AM -0600, Hanasaki JiJi wrote: Anything security related that would cause wtmp to be zero'ed out? Other than someone breaking into your system and clearing wtmp as part of an effort to cover their tracks? wtmp is rotated monthly by logrotate. -- see shy jo pgpW1iYFSsGll.pgp Description: PGP signature
Re: postfix in qmail out proftpd in pureftpd
WebMaster wrote: (pureftpd is more secure than proftpd) it s because we can read on pureftpd.org: the number of root exploits found since the very first released version is zero we can t read things like that on postfix.org and proftpd.org You definitly need to check out vsftpd then. It's got very secure it it's _name_, so it must be secure! -- see shy jo, who finds it a find and well-designed ftp server nontheless pgpoRVY4GwurI.pgp Description: PGP signature
Re: [SECURITY] [DSA 149-1] New glibc packages fix security related problems
Renee Landers wrote: But I choose to reboot since even init is linked with libc. Obviously, that's not always an option in a production environment. Debian's libc6 package restarts init on upgrade (telinit u). -- see shy jo
Re: [SECURITY] [DSA 122-1] New zlib other packages fix buffer overflow
Jor-el wrote: Doesnt dpkg also compile with a static zlib? Why does it not make this list? Yeah, dpkg-deb does. Presumaly you already have to trust debs you install, but this could affect using dpkg to examine the contents of untrusted debs.. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 122-1] New zlib other packages fix buffer overflow
Jor-el wrote: Doesnt dpkg also compile with a static zlib? Why does it not make this list? Yeah, dpkg-deb does. Presumaly you already have to trust debs you install, but this could affect using dpkg to examine the contents of untrusted debs.. -- see shy jo
Re: SpamAssassin (Was Re: SOME ITEMS THAT YOU MAY BE INTERESTED IN OR BE ABLE TO ADVISE ME ON)
Oliver M . Bolzer wrote: I've heard Razor is (configurabule) part of SpamAssassin. I'd recommend disabling that check because somebody is tagging about 1/3 of Bugtraq mail in Razor thus sending it to the Spam folder. Razor only scores 3 points in spamassassin, so a mail would need to exhibit two more points of spammishness to be flagged by spamassassin. I've not seen any false positives frm bugtraq. I consider razor mostly useless by itself, but it's still worth something as a part of a larger tool. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
Andrew Suffield wrote:
On Tue, Jan 22, 2002 at 11:42:49AM +, Colin Phipps wrote:
On Tue, Jan 22, 2002 at 01:59:44AM +0100, Christian Jaeger wrote:
I just wanted to point it out here, since I wasn't sure whether I
should file a bug report against fakeroot for writing suid through,
I consider it a bug; it's introducing a third permissions+ownership
state that was requested by neither the author nor the builder of the
package.
snip
So file some bugs about it. Start with debhelper, and have
debian/{tmp,$package} directories made 0700, then lintian, and when
it's become generally accepted, propose an amendment to policy.
I doubt I'd accept such a bug. It looks like a misdesign of fakeroot,
and should be fixed in fakeroot. I agree with Colin Phipps's message
entirely.
--
see shy jo
Re: Once again: Spam (from hananet.net, korea)
Dietmar Braun wrote: from USA and Germany, we normally get also mails we want and we need. From Korea/China and other spammers heaven, we get nothing but spam - there is no mail from these countries I had to admit that I wanted it... Ignoring in your blind nationalistic fury that there are indeed Debian developers in both those countries[1], of course. -- see shy jo [1] For values of Korea approaching South Korea, anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Once again: Spam (from hananet.net, korea)
Dietmar Braun wrote: from USA and Germany, we normally get also mails we want and we need. From Korea/China and other spammers heaven, we get nothing but spam - there is no mail from these countries I had to admit that I wanted it... Ignoring in your blind nationalistic fury that there are indeed Debian developers in both those countries[1], of course. -- see shy jo [1] For values of Korea approaching South Korea, anyway.
Re: mounting /tmp noexec (was: Campus Computers)
Ian wrote: why is this? Surely it is better security to do so? [EMAIL PROTECTED]:~ls -l ./ls -rw---1 joey joey43916 Dec 26 22:46 ./ls [EMAIL PROTECTED]:~/lib/ld-2.2.4.so ./ls CVS aalib.nohack.diff doc lsscreenshot.png GNUstep binhtml mail src adebian lib package-sync.log tmp If you remove the execute bit from ld.so to avoid this, you in turn break execution of all deymaically linked libc6 programs. So sure, noexec does raise the bar tiny little bit, just because an attacker needs to remember to try this trick, and needs to be able to do so in their exploit. Anyway, I would like to make debconf (er, really apt-utils) use a different temporary directory, but I have not been able to come up with better one so far. -- see shy jo
Re: Bug#77257: FWD: Joe's Own Editor File Link Vulnerability
Herbert Xu wrote: On Sat, Nov 18, 2000 at 11:26:13AM -0500, Jacob Kuntz wrote: what's wrong with the current practice of putting deadjoe in the current directory? cwd == /tmp Belive it or not, it is actually possible to write files to /tmp securely. It's pretty silly to contemplating changing the bahavior of joe when it can just be fixed. -- see shy jo
Re: Bug#77257: FWD: Joe's Own Editor File Link Vulnerability
Alexander Viro wrote: a) take a look at /etc/init.d/bootmisc.sh. Around Cleaning: /tmp, that is. So you're editing a file in /tmp and you're worried about the DEADJOE file lying around after a reboot? What about the file itself? b) several editing sessions in parallel. Well yeah, the file is a dumb idea. -- see shy jo
