Re: DSA for CVE-2016-5696 (off-path blind TCP session attack)
On Fri, 12 Aug 2016 17:46:56 +0200, Jakub Wilk wrote: > * Salvatore Bonaccorso <car...@debian.org>, 2016-08-12, 17:35: >>mitigation could be used as per https://lwn.net/Articles/696868/ . > > This is behind paywall at the moment. Anyone who wishes to read this may use the following link: https://lwn.net/SubscriberLink/696868/4d074b4d12dcb3dc/ And if you like the article, consider subscribing to LWN! Now that I think about it, I'm pretty sure there's a group membership available to all DDs anyway. -- Sam Morris https://robots.org.uk/ PGP: rsa4096/5CDA27B9 CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
Re: Certification Authorities are recommended to stop using MD5 altogether
On Wed, 31 Dec 2008 02:39:53 +0100, Cristian Ionescu-Idbohrn wrote: http://www.win.tue.nl/hashclash/rogue-ca/ Could some skilled person comment on the article? I noticed around 20 certificates distributed with the package ca-certificates have Signature Algorithm: md5WithRSAEncryption. Reason to worry? Nah. What we really need to do, is patch the crypto libs use the certificates in ca-certificates to disable the use of broken algorithms such as MD5. But at the end of the day, unless you actually do OCSP validation of every single connection you make, you are already running the risk of being MitM'd. And even then, you are basically relying on the CA companies to perform the task of validating the identities of certificate-holders, when they make a lot more money by simply rubber-stamping everything they see. :) Cheers, Happy new year, and sleep well. ;) -- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Certification Authorities are recommended to stop using MD5 altogether
On Wed, 31 Dec 2008 02:39:53 +0100, Cristian Ionescu-Idbohrn wrote: http://www.win.tue.nl/hashclash/rogue-ca/ Could some skilled person comment on the article? I noticed around 20 certificates distributed with the package ca-certificates have Signature Algorithm: md5WithRSAEncryption. Reason to worry? Cheers, As an aside to my previous post, you may find the following link interesting: https://bugzilla.mozilla.org/show_bug.cgi?id=471539 Maybe in a few years, NSS will have disabled the use of MD5 and the ancient MD2 algorithm. I wonder how many other insecure algorithms are still lurking in NSS, OpenSSL, GNU TLS, Java, etc... -- Sam Morris https://robots.org.uk/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Find installed contrib and non-free packages
On Fri, 13 Jun 2008 07:17:54 +1000, Andrew Vaughan wrote: On Friday 13 June 2008 06:10, W. Martin Borgert wrote: On Thu, Jun 12, 2008 at 12:27:12PM +0200, Vladislav Kurz wrote: 1. remove contrib and non-free from /etc/apt/sources.list 2. run dselect (update, select) and you will see all contrib and non-free packages as obsolete/local packages. Good, because it will show other suspects as well. E.g. packages from non-Debian apt sources, which are also unsupported security-wise. I wonder how I can achieve the same using just apt-get/apt-cache? I remember, that I once wrote a script using python-apt to get this information, but the script is lost :~( In lenny $ aptitude search ~o In etch I think this will work (but very slow) $ for i in `aptitude search ~i -F %p` ; do apt-show-versions $i ; done | grep No available version in archive$ I prefer 'aptitude search ~S~i!~Odebian' over ~o because it also lists packages that are installed, but for which the installed version is not available from any apt repositories, whereas ~o will not. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator
On Wed, 14 May 2008 07:59:58 +0200, Yves-Alexis Perez wrote: On mar, 2008-05-13 at 23:39 -0300, Henrique de Moraes Holschuh wrote: It is probably worth a lot of effort to fully map the entire set of keys the broken openssl could generate, and find a very fast way to check if a key belong to that set. And add that to openssl upstream (to automatically fail any verification done using such keys). Ubuntu apparently made it. See http://www.ubuntu.com/usn/usn-612-2 Not quite... Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases). I agree it would be neat if someone with a powerful machine could generate all possible keys. I don't know how long that would take however... -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1370-2] New phpmyadmin packages fix several vulnerabilities
On Tue, 2007-09-11 at 01:38 +0200, Thijs Kinkhorst wrote: For the stable distribution (etch) these problems have been fixed in version 2.9.0.3-4. Is this correct? This version seems to be lower than the version in etch, and in etch/updates: $ pol phpmyadmin phpmyadmin: Installed: 4:2.9.1.1-4 Candidate: 4:2.9.1.1-4 Version table: *** 4:2.9.1.1-4 0 540 http://security.debian.org etch/updates/main Packages 100 /var/lib/dpkg/status 4:2.9.1.1-3 0 540 http://ftp.de.debian.org etch/main Packages -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 signature.asc Description: This is a digitally signed message part
Re: ProFTPD still vulnerable (Sarge)
On Thu, 30 Nov 2006 07:28:53 +0100, Lupe Christoph wrote: The attacks ceased before I noticed, so I was not able to capture a TCP stream. I would just like to alert people that there is still some vulnerability in the ProFTPD code that was not fixed by DSA-1218-1. Indeed, see http://idssi.enyo.de/tracker/CVE-2006-5815 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399070. I guess an update is in the works somewhere. :) -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remote Root In Nvidia xserver Driver
On Tue, 17 Oct 2006 21:53:49 -0400, Noah Meyerhans wrote: However, as I read it, it sounds like you can only run arbitrary code if you are actually accessing the X server directly via a client. While this client can be local or remote, nobody is going to allow unauthenticated remote clients to access their X server, so this might not be so bad... I disagree. SSHing to a compromised host should not open the client machine up to security vulnerabilities of this kind. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remote Root In Nvidia xserver Driver
On Wed, 18 Oct 2006 11:48:18 +0100, Dominic Hargreaves wrote: On Wed, Oct 18, 2006 at 10:42:05AM +, Sam Morris wrote: On Tue, 17 Oct 2006 21:53:49 -0400, Noah Meyerhans wrote: However, as I read it, it sounds like you can only run arbitrary code if you are actually accessing the X server directly via a client. While this client can be local or remote, nobody is going to allow unauthenticated remote clients to access their X server, so this might not be so bad... I disagree. SSHing to a compromised host should not open the client machine up to security vulnerabilities of this kind. Huh? sshing to a compromised machine with X forwarding enabled is already a big enough problem without adding root exploits. Don't ssh with X forwarding to an untrusted machine. Ever. The point is that I may trust the machine, it may have been compromised without me finding out. I should not have to send the hackers who did it an email saying ok fellas, you got me, here are all my root passwords. X is not a secure protocol and with access to your X server a program can wreak havoc on anything you do on that X server including capturing passwords and other sensitive data. It's not an issue specific to this vulnerability. Isn't the X11 security extension designed to help with these issues? But anyway, you can't deny that this vulnerability increases a users' attack surface significantly. Especially since someone else pointed out that a Flash movie or Java applet could exploit the vulnerability (i.e., you don't need to use X11 forwarding to make the vulnerability into a remote one). Dominic. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remote Root In Nvidia xserver Driver
On Wed, 18 Oct 2006 01:38:25 +0100, Nick Boyce wrote: Regarding the remote root hole in Nvidia's closed-source binary xserver driver announced today by Rapid7 : http://download2.rapid7.com/r7-0025/ and being discussed all over the place : http://it.slashdot.org/article.pl?sid=06/10/16/2038253 http://kerneltrap.org/node/7228 it looks to me as though the hole is not present in the version of the driver packaged for Sarge (1.0.7174). The Rapid7 bulletin asserts the hole is present in Linux driver versions 8762 and 8774 - and _probably_ earlier versions. [ ... ] Just for the sake of calm (my calm) can anyone else confirm this ? The legacy nvidia graphics drivers should also be checked. Cheers Nick Boyce -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preventing Symlink Attacks...
On Mon, 18 Sep 2006 21:37:21 +0100, Conall O'Brien wrote: Hello, As suggested by Joey Shulze, I'd like input from people here on how to deal with potential symlink attacks for my queuegraph package now in sid. Queuegraph is a simple script. It has a shell script which works out Postfix queue statistics, then saves them in an rrd DB (in /var/lib/queuegraph/ ). Seperately, a perl CGI script (in /usr/lib/cgi-bin/ ) processes the rrd DB when called to generate RRD graphs. I've made modifications to the tmp path in the CGI script to store the generated .png graphs in /var/tmp/queuegraph/ What is the best way for me to protect from symlink attacks? Or should I change this path to say /var/cache/queuegraph/ (as done in the bindgraph package, which has similarities to my package) Suggestions thoughts welcome. It sounds like the easiest solution would be to avoid using a shared directory entirely, and instead create a dedicated directory at /var/cache/queuegraph. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILES has hints and pointers for doing stuff securely in shared directories such as /tmp and /var/tmp. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPG errors from apt update
On Thu, 31 Aug 2006 16:52:06 -0700, Hedges, Mark wrote: But then, I tried apt-get update about 5 minutes later with NO CHANGES and got these erorrs: Failed to fetch http://ftp.us.debian.org/debian/dists/testing/main/binary-i386/PackagesI ndex MD5Sum mismatch [...] $ host ftp.us.debian.org ftp.us.debian.org has address 128.101.240.212 ftp.us.debian.org has address 204.152.191.7 ftp.us.debian.org has address 216.37.55.114 ftp.us.debian.org has address 35.9.37.225 It would be helpful if apt-get informed the user of which server it is having problems with to ease the tasks of troubleshooting and contacting the correct mirror admin. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When are security updates effective?
On Thu, 31 Aug 2006 09:55:26 +0200, Rolf Kutz wrote: * Quoting Mikko Rapeli ([EMAIL PROTECTED]): On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote: Mikko Rapeli wrote: Could Debian security advisories help a bit, since the people making the packaging changes propably know how to make the changes effective on a running installation too? If there's anything special to do (e.g. kernel or glibc) we alredy add this to the DSA text. Yes, that's great, but some of the non-special cases are not that obvious. Should I reboot or at least restart kdm after libtiff4 update? On one host I get the feeling I don't since 'lsof 2/dev/null | grep libtiff' returns nothing. Then again this would suggest, that at least kde/kdm needs to be restarted: # apt-cache rdepends libtiff4|grep kde kdelibs4 kdegraphics-kfile-plugins So which one is it? You can check with # lsof +L1 It will show you open Files that have been unlinked. If any of those are part of the upgraded packages, you restart that process. - Rolf Note that this has been broken since at most Linux 2.6.8. Relying on it may cause you to not notice that some processes need to be restarted after upgrading a package containing a shared library. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264985 I currently rely on both lsof and the psdel script I wrote, link to from that bug report. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPG errors from apt update
On Thu, 31 Aug 2006 11:50:44 -0700, Robert Dobbs wrote: That key is in debian-keyring, but was not in apt. I had to manually add the /usr/share/keyrings/debian-keyring.* keyrings to ~root/.gnupg/gpg.conf, then extract the keys and add with apt-key. Shouldn't this be automatic? But it does not matter. I still get the same error on `apt-get update`: W: GPG error: http://security.debian.org stable/updates Release: The following signatures were invalid: BADSIG 010908312D230C5F Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] W: GPG error: http://security.debian.org testing/updates Release: The following signatures were invalid: BADSIG 010908312D230C5F Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] Isn't BADSIG indicative of a bad signature rather than a missing key? -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 946-1] New sudo packages fix privilege escalation
Marc Haber wrote: For unstable Defaults = env_reset need to be addeed to /etc/sudoers manually. Why is this only necessary on unstable systems? The security update doesn't seem to add this on stable systems automatically, so it might be necessary to manually add this on stable and testing as well. It seems to be part of sudo itself on stable: $ sudo -s env TERM=xterm LANG=en_GB.UTF-8 LANGUAGE=en_GB:en PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin LOGNAME=root USER=root SUDO_COMMAND=/usr/bin/env SUDO_USER=sam SUDO_UID=1000 SUDO_GID=1000 Note that this behaviour differs from the effect of env_reset in sudoers(5). SHELL and HOME(!) are discarded, but they should be reset to 'default values'. LANG, LANGUAGE, and LC_* are passed though, but they should be discarded. The version in unstable 'fixes' the bug by adding env_reset to the default /etc/sudoers; therefore users who upgrade from stable will re-introduce this security hole unless they alter /etc/sudoers themselves. A NEWS entry should be added to the package in unstable so that those who upgrade know to make this change! Greetings Marc -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hardening checkpoints
kevin bailey wrote: 2. firewall not i'm not sure about the need for a firewall - i may need to access the server over ssh from anywhere. also, to run FTP doesn't the server need to be able to open up a varying number of ports. You can limit your FTP server to listen for data connections on a specific port only (eg, ftp-data, or 20). Then you only have to allow connections to ports 20 and 21. This takes care of passive mode users; active mode involves the FTP server connecting back to the users for data transfer, and so relies on the users' own firewall policies permitting the connections. You could also set up SSL/TLS so that the users whose clients support it recieve the benefits of an encrypted session. BTW - FTP *has* to be available - many of the users only know how to use FTP. In that case it would be best to secure the machine assuming that the user accounts have already been compromised. :) Can the users upload PHP scripts? In that case anyone sniffing passwords from your FTP sessions can run their code on your system... You could configure Apache to run each user's scripts as the user in question, rather than www-data. This is rather difficult to do however, and perhaps impossible to do in a way that doesn't suck. Keep on top of any privilige escalation bugs in the kernel since these will allow the hypothetical attacker to take over the system entirely. The stock Debian kernels recieved a security update yesterday... it was a long time in coming but I believe the only issues in the stock kernels have been fairly uninteresting DOS attacks anyway. 4. enhance authentication maybe set up ssh access by authorised keys only - but again this has a problem when i need to log in to the server from a putty session on a PC in an internet cafe . An alternative to public key authentication is to make use of a one-time password system. There are packages for OPIE in Debian, which challenges you with a string of text that you enter into your OPIE calculator (you can get dedicated calculators, or software to run on a PDA or mobile phone) along with a secret password. The calculator gives you the response which you use to log in to the server. A more low-tech solution is OTPW[0]. You simply print out 25 or so pregenerated passwords into a bit of paper (write the system's SSH host key on the back if you don't remember it). To log in, concatenate a secret 'prefix password' with the next password on the list. In both cases, the paper/calculator is useless to an attacker without knowledge of both your password and the particular host to which it applies. Until all public access PCs have some kind of standardised smart card reader that we can use for our SSH private keys and PGP keys, one-time password systems are probably more secure if you must use untrusted public terminals. Consider that a PC that you plug your usb disk into may have been configured to make a copy of anything it finds for itself, either by the crooked owner of an Internet cafe, or a user who is mining the computers for interesting passwords and other data... [0] http://www.cl.cam.ac.uk/~mgk25/otpw.html 5. ongoing security sign up to email lists to monitor security issues RE the services used. get server to run chkrootkit regularly and email results. run snort to check for attacks. get script to run and check status of server every day. Logwatch or logcheck can help with this. An alternative approach is to configure syslog to log everything of ERROR priority or higher to a file, eg /var/log/important. Then put an entry such as the following into /etc/crontab: @hourly root logtail /var/log/important | mail -e -s Important log events on $HOSTNAME root Another good one is: @daily apt-get -qq update apt-get -qq --dry-run upgrade | mail -e -s Upgradable packages on $HOSTNAME root Also check out /etc/security/limits.conf; it will allow you to set up resource limits for your users. See getrlimit(2) and the administrator's guide from the libpam-doc package. -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Version of 'cvs' in security archive
$ apt-cache policy cvs cvs: Installed: (none) Candidate: 1:1.12.9-13 Version table: 1:1.12.9-13 0 600 http://ftp.uk.debian.org sarge/main Packages 1.11.1p1debian-11 0 600 http://security.debian.org sarge/updates/main Packages Is the version in stable too high, or is the version in stable/updates too low? :) -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt sources.list: inconsistency between sarge and stable
Is there a difference in the output of apt-cache policy php4 when you have a 'sarge' and a 'stable' line? -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mozilla-firefox 1.0.4-2 security holes (was Re: Security fixes for mozilla and firefox in Sarge?)
I compiled the following list this morning: CAN-2004-0718 CAN-2005-1937 = MFSA-2005-51 CAN-2005-2114 CAN-2005-2260 = MFSA-2005-45 CAN-2005-2261 = MFSA-2005-46 CAN-2005-2262 = MFSA-2005-47 CAN-2005-2263 = MFSA-2005-48 CAN-2005-2264 = MFSA-2005-49 CAN-2005-2265 = MFSA-2005-50 CAN-2005-2266 = MFSA-2005-52 CAN-2005-2267 = MFSA-2005-53 (embargoed until 2005-08-01) CAN-2005-2268 = MFSA-2005-54 CAN-2005-2269 = MFSA-2005-55 CAN-2005-2270 = MFSA-2005-56 (embargoed until 2005-08-01) CAN-2005-2395 Sources: http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox for (= CAN-2005-1937) http://www.mozilla.org/projects/security/known-vulnerabilities.html#Firefox Debian bug #318061 sort-of covers some of the above issues, but the bts says it will be archived in 19 days, even though the bug is still open for the version in Stable. Is this normal? -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security fixes for mozilla and firefox in Sarge?
Michael Stone wrote: IMO, if people really intend for the package to have no security support in the long term then it should exist only in volatile. I think it is dangerously irresponsible to ship software we do not intend to support. Would we have to move Sarge's kernel packages to 'volatile' then? ;) I think that the split that Ubuntu makes[0] between 'main' and 'universe' is a good idea. Of course, even they don't backport security fixes all the time--they just went from mozilla-firefox 1.0.2 to 1.0.6 in main. But back to Debian. The system we have at the moment is not working: users are installing packages from the stable release, in the assumption that the packages are supported; in reality these packages are not getting updated. From a user's point of view, this assumption is perfectly reasonable, especially given statements such as: Debian takes security very seriously. Most security problems brought to our attention are corrected within 48 hours. [1] It was easy to make such a promise back in 1997, but today Debian is much larger. If the security team is unable to function[2] such that the above statement still holds true, then either the statement, or the job that the team does, must be changed. One way to solve the problem would be to partition the archive into supported and unsupported packages: deb http://mirror/debian sarge main contrib non-free deb http://mirror/debian sarge/unsupported main contrib non-free The idea is to make sure that the a user who doesn't know just how bone-grindingly hard the process of providing security updates is, will only be presented with packages that are supported, unless he enables the stable/unsupported repository himself--similar to how the default configuration of Ubuntu only has 'main' enabled by default. Such a setup would be better than providing a simple list of supported/unsupported packages, IMO. Another way to do it is more of a break with the way that Debian has traditionally operated: allow new versions into 'unsupported'. This would make 'unsupported' more like 'volatile', but perhaps with a policy that allows only minor version updates. Two problems with this are that there are no standards between different projects as to what constitutes a minor update; and that you're still screwed when upstream announces the end of support for the branch that 'unsupported' would be tracking (e.g., mozilla-firefox-1.0.x). Enough detail. I don't claim to know where on the scale of 'unsupported' - 'volatile' - backports that Firefox and other such packages should end up. I merely hope to raise awareness of the fact that the current security mechanisms don't appear to be working, and to start a discussion of what can be done about it. [0] http://www.ubuntulinux.org/ubuntu/components [1] http://www.debian.org/security/ [2] Wording this is difficult. I certainly don't mean to imply that the security team is under-performing. I know they are only volunteers, and that providing security updates is a damn hard job, especially when upstream doesn't care to help backporting security fixes to 'obsolete' versions of their software. :) -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security fixes for mozilla and firefox in Sarge?
Florian Weimer wrote:
I'm not sure if there will be uploads of new Firefox (or Mozilla)
version to the volatile distribution. A first step is building a new
Firefox package on sarge, and I'm not aware of anyone doing this.
I'm attaching a diff against mozilla-firefox_1.0.6-1.diff that makes
Firefox 1.0.6 build on Sarge.
I think it's up to the package's maintainer to propose that it go into
Volatile (if indeed Volatile is a suitable place for it--backports.org
seems like a better fit, once it starts hosting packages for Sarge).
--
Sam Morris
http://robots.org.uk/
PGP key id 5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
--- mozilla-firefox_1.0.6-1.diff2005-07-28 04:33:42.0 +0100
+++ mozilla-firefox_1.0.6-1~sarge.diff 2005-07-28 04:33:36.0 +0100
@@ -15803,56 +15803,6 @@
case NS_MOUSE_SCROLL:
if (nsEventStatus_eConsumeNoDefault != *aStatus) {
nsresult rv;
mozilla-firefox-1.0.6.orig/gfx/idl/nsIFreeType2.idl
-+++ mozilla-firefox-1.0.6/gfx/idl/nsIFreeType2.idl
-@@ -76,11 +76,13 @@
- native FT_Sfnt_Tag(FT_Sfnt_Tag);
- native FT_Size(FT_Size);
-
--[ptr] native FTC_Image_Desc_p(FTC_Image_Desc);
-+native FTC_ImageType(FTC_ImageType);
- native FTC_Face_Requester(FTC_Face_Requester);
- native FTC_Font(FTC_Font);
--native FTC_Image_Cache(FTC_Image_Cache);
-+native FTC_ImageCache(FTC_ImageCache);
- native FTC_Manager(FTC_Manager);
-+native FTC_Node(FTC_Node);
-+native FTC_Scaler(FTC_Scaler);
-
- // #ifdef MOZ_SVG
- [ptr] native FT_Matrix_p(FT_Matrix);
-@@ -99,7 +101,7 @@
-
- readonly attribute FT_Library library;
- readonly attribute FTC_Manager FTCacheManager;
--readonly attribute FTC_Image_Cache ImageCache;
-+readonly attribute FTC_ImageCache ImageCache;
-
- voiddoneFace(in FT_Face face);
- voiddoneFreeType(in FT_Library lib);
-@@ -115,16 +117,17 @@
- voidoutlineDecompose(in FT_Outline_p outline,
- in const_FT_Outline_Funcs_p funcs, in voidPtr p);
- voidsetCharmap(in FT_Face face, in FT_CharMap charmap);
--voidimageCacheLookup(in FTC_Image_Cache cache, in FTC_Image_Desc_p
desc,
-- in FT_UInt gindex, out FT_Glyph glyph);
--voidmanagerLookupSize(in FTC_Manager manager, in FTC_Font font,
-- out FT_Face face, out FT_Size size);
-+voidimageCacheLookup(in FTC_ImageCache cache, in FTC_ImageType type,
-+ in FT_UInt gindex, out FT_Glyph glyph,
-+ out FTC_Node node);
-+voidmanagerLookupSize(in FTC_Manager manager, in FTC_Scaler scaler,
-+ out FT_Size size);
- voidmanagerDone(in FTC_Manager manager);
- voidmanagerNew(in FT_Library lib, in FT_UInt max_faces,
-in FT_UInt max_sizes, in FT_ULong max_bytes,
-in FTC_Face_Requester requester, in FT_Pointer
req_data,
-out FTC_Manager manager);
--voidimageCacheNew(in FTC_Manager manager, out FTC_Image_Cache cache);
-+voidimageCacheNew(in FTC_Manager manager, out FTC_ImageCache cache);
- /* #ifdef MOZ_SVG */
- void glyphTransform(in FT_Glyph glyph, in FT_Matrix_p matrix,
- in FT_Vector_p delta);
--- mozilla-firefox-1.0.6.orig/gfx/src/gtk/fontEncoding.properties
+++ mozilla-firefox-1.0.6/gfx/src/gtk/fontEncoding.properties
@@ -54,8 +54,8 @@
@@ -15888,368 +15838,6 @@
FtFuncList nsFreeType2::FtFuncs [] = {
{FT_Done_Face,NS_FT2_OFFSET(nsFT_Done_Face),
PR_TRUE},
{FT_Done_FreeType,NS_FT2_OFFSET(nsFT_Done_FreeType),
PR_TRUE},
-@@ -110,11 +110,11 @@
- {FT_New_Face, NS_FT2_OFFSET(nsFT_New_Face),
PR_TRUE},
- {FT_Outline_Decompose,NS_FT2_OFFSET(nsFT_Outline_Decompose),
PR_TRUE},
- {FT_Set_Charmap, NS_FT2_OFFSET(nsFT_Set_Charmap),
PR_TRUE},
-- {FTC_Image_Cache_Lookup, NS_FT2_OFFSET(nsFTC_Image_Cache_Lookup),
PR_TRUE},
-- {FTC_Manager_Lookup_Size, NS_FT2_OFFSET(nsFTC_Manager_Lookup_Size),
PR_TRUE},
-+ {FTC_ImageCache_Lookup, NS_FT2_OFFSET(nsFTC_ImageCache_Lookup),
PR_TRUE},
-+ {FTC_Manager_LookupSize, NS_FT2_OFFSET(nsFTC_Manager_LookupSize),
PR_TRUE},
- {FTC_Manager_Done,NS_FT2_OFFSET(nsFTC_Manager_Done),
PR_TRUE},
- {FTC_Manager_New, NS_FT2_OFFSET(nsFTC_Manager_New),
PR_TRUE},
-- {FTC_Image_Cache_New, NS_FT2_OFFSET(nsFTC_Image_Cache_New),
PR_TRUE},
-+ {FTC_ImageCache_New, NS_FT2_OFFSET(nsFTC_ImageCache_New),
PR_TRUE},
- // #ifdef MOZ_SVG
- {FT_Glyph_Transform, NS_FT2_OFFSET(nsFT_Glyph_Transform),
PR_TRUE},
- {FT_Get_Kerning, NS_FT2_OFFSET(nsFT_Get_Kerning),
PR_TRUE},
-@@ -282,20 +282,21 @@
- }
-
- NS_IMETHODIMP
--nsFreeType2::ImageCacheLookup(FTC_Image_Cache cache, FTC_Image_Desc *desc,
-- FT_UInt
Re: Security risks due to packages that are no longer part of Debian?
Florian Weimer wrote: If a User upgrades his woody system to sarge and one package that has been part of woody is now no longer part of Debian nor being superseded by another package, will apt-get warn the user that this package is a potential security risk as Debian does not monitor nor provide fixes for reported security issues in this package? No, of course not. For such a cases it would even be a reasonable advice to have both, woody/updates and sarge/updates, in the sources.list, or? I doubt that this will work in general. A tool which lists all packages which are no longer downloadable from any APT source would be more helpful, I think. Does it already exist? You can use aptitude to discover obsolete packages on your system. See http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-obsolete for more info. -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
{Spam?} Re: woody kernel image
Michelle Konzack wrote: Where is it posted that the dropped support for 2.4.18? It was on debian-devel and debian-kernel They told, there are too much kernels to maintain and droped 2.4.(18-22) They sugested to use one of the Backports. Wow, I missed that! Should not the kernel-image-2.4.28-* packages be removed from the archive, since they are unsupported, and *very* dangerous to use? Thanks to Norbert Tretkowsky (nobse) for http://www.backports.org/ Hear, hear! -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 Fingerprint 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
{Spam?} Re: {Spam?} Re: woody kernel image
Sam Morris wrote: Wow, I missed that! Should not the kernel-image-2.4.28-* packages be ^ should be 2.4.18, sorry :) -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 Fingerprint 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 Lhr wrote: Greetings, 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? Because of running an terminal-Server I'd like to know, what's going on at these issues. Add CAN-2004-0554 as well--bug #261521 has been open against kernel-image-2.4.18-1-i386 (but not against kernel-image-2.4.18-i386) since July wish no updates. I believe someone posted here a few months ago asking about the bug, and was told that updates were being prepared--but that has not yet happened. :( Thanks in advance, Keep smiling yanosz -- Regards, Sam Morris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerability
Florian Weimer wrote: * Christian Storch: Use a backport of PHP 4.3.10. Apparently, there is no other way at this stage to be sure. (Upstream no longer supports PHP 4.1.x.) What about a kind of fork into php4-1 for woody? The diff from 4.3.9 to 4.3.10 is about 4,000 lines long. It contains other changes, of course, but you still have to isolate the security fixes. However, in the past, the PHP team neither provided clear descriptions of security bugs, nor were the CVS log messages enlightening. From Debian's point of view, the situation gets more difficult as other distributions withdraw PHP 4.1.x support. What's worse, some of the changed parts are not covered by the PHP test suite. This means that regression testing is not possible (until the update has been installed on a large number of machines). Or are there any considerations within security team about patching 4.1 in woody? We are talking about a person-week of work, for someone who is not familiar with the PHP code base. Significantly less work is required if upstream is somewhat supportive and provides a clear description of the bugs, including proper test cases. I'm sure saying this won't win my any friends, but should software that the security team is unable to support have a place in a stable release of Debian? The discussion about volitile.debian.org showed that a newer branch of software can't very well be backported to Stable when upstream drops support for the version that Stable includes, so that's not an option. To mention nothing about maintaining the Stability of a stable release. But perhaps it would be best to mark software that is unsupportable as such? If I ran apt-get install php4 on a newly installed system, it would be nice to see a message stating something like: The software you are installing contains known security flaws, and is no longer supported by upstream. Since the changes necessary to fix the flaws are too great to be allowed into a stable Debian release. We recommend that you do not install php4 from the stable archive. Instead, find a backport or otherwise install the latest version yourself. In fact, does anyone keep a list of software with problems of this nature? Regards, -- Sam Morris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
