[SECURITY] [DSA 443-1] New xfree86 packages fix multiple vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 443-1 [EMAIL PROTECTED] http://www.debian.org/security/ Matt Zimmerman February 19th, 2004 http://www.debian.org/security/faq - -- Package: xfree86 Vulnerability : several Problem-Type : remote Debian-specific: no CVE Ids: CAN-2003-0690 CAN-2004-0083 CAN-2004-0084 CAN-2004-0106 CAN-2004-0093 CAN-2004-0094 A number of vulnerabilities have been discovered in XFree86: CAN-2004-0083: Buffer overflow in ReadFontAlias from dirfile.c of XFree86 4.1.0 through 4.3.0 allows local users and remote attackers to execute arbitrary code via a font alias file (font.alias) with a long token, a different vulnerability than CAN-2004-0084. CAN-2004-0084: Buffer overflow in the ReadFontAlias function in XFree86 4.1.0 to 4.3.0, when using the CopyISOLatin1Lowered function, allows local or remote authenticated users to execute arbitrary code via a malformed entry in the font alias (font.alias) file, a different vulnerability than CAN-2004-0083. CAN-2004-0106: Miscellaneous additional flaws in XFree86's handling of font files. CAN-2003-0690: xdm does not verify whether the pam_setcred function call succeeds, which may allow attackers to gain root privileges by triggering error conditions within PAM modules, as demonstrated in certain configurations of the MIT pam_krb5 module. CAN-2004-0093, CAN-2004-0094: Denial-of-service attacks against the X server by clients using the GLX extension and Direct Rendering Infrastructure are possible due to unchecked client data (out-of-bounds array indexes [CAN-2004-0093] and integer signedness errors [CAN-2004-0094]). Exploitation of CAN-2004-0083, CAN-2004-0084, CAN-2004-0106, CAN-2004-0093 and CAN-2004-0094 would require a connection to the X server. By default, display managers in Debian start the X server with a configuration which only accepts local connections, but if the configuration is changed to allow remote connections, or X servers are started by other means, then these bugs could be exploited remotely. Since the X server usually runs with root privileges, these bugs could potentially be exploited to gain root privileges. No attack vector for CAN-2003-0690 is known at this time. For the stable distribution (woody) these problems have been fixed in version 4.1.0-16woody3. For the unstable distribution (sid) these problems have been fixed in version 4.3.0-2. We recommend that you update your xfree86 package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/x/xfree86/xfree86_4.1.0-16woody3.dsc Size/MD5 checksum: 1512 596b339b1a1ab8c1aeebe949a7e77076 http://security.debian.org/pool/updates/main/x/xfree86/xfree86_4.1.0-16woody3.diff.gz Size/MD5 checksum: 1600904 d0ab158eaf2b1a49d17470b138e99fe8 http://security.debian.org/pool/updates/main/x/xfree86/xfree86_4.1.0.orig.tar.gz Size/MD5 checksum: 54433247 ea7a32e6a81a850e9f19428f3104c300 Architecture independent components: http://security.debian.org/pool/updates/main/x/xfree86/x-window-system_4.1.0-16woody3_all.deb Size/MD5 checksum:60486 27fbccef0a1e87466eae49534b492f32 http://security.debian.org/pool/updates/main/x/xfree86/xfonts-100dpi-transcoded_4.1.0-16woody3_all.deb Size/MD5 checksum: 8333716 23dcab5cbf8daffe02eb6cded5da96b4 http://security.debian.org/pool/updates/main/x/xfree86/xfonts-100dpi_4.1.0-16woody3_all.deb Size/MD5 checksum: 4442612 379489c2b77427f1640525568e5ba4c0 http://security.debian.org/pool/updates/main/x/xfree86/xfonts-75dpi-transcoded_4.1.0-16woody3_all.deb Size/MD5 checksum: 7225924 0e2b47660cbe103fbd67275e55c7da53 http://security.debian.org/pool/updates/main/x/xfree86/xfonts-75dpi_4.1.0-16woody3_all.deb Size/MD5 checksum: 3931790 eb3ecbf1e2a453af48de6b9fb8e23f2f http://security.debian.org/pool/updates/main/x/xfree86/xfonts-base-transcoded_4.1.0-16woody3_all.deb Size/MD5 checksum: 1105542 30257b1f4ff435f24a1a96f0820f0119 http://security.debian.org/pool/updates/main/x/xfree86/xfonts-base_4.1.0-16woody3_all.deb Size/MD5 checksum: 5028916 f0e09d48bd43a2ebdcb0da701a67ce7f
Re: [SECURITY] [DSA 443-1] New xfree86 packages fix multiple vulnerabilities
With the current thread in this list: thanks, Matt team - I'm quite satisfies with the way Debian handles security updates currently. And some people need to remind themselves that Debian is a volounteer project and is open source - so, if you want more/faster security updates, hire somebody to do it for you, and if you're feeling generous, allow this person to contribute his(her) efforts back to Debian. On Friday 20 February 2004 07.58, Matt Zimmerman wrote: For the stable distribution (woody) these problems have been fixed in version 4.1.0-16woody3. For the unstable distribution (sid) these problems have been fixed in version 4.3.0-2. So this opens the questions - when will 4.3 hit testing? Was there recent summary? - is it worth it to upgrade now from testing? Stability? Performance? OTOH, I guess the DSA is not urgent at all as my workstations are single-user with no remote X configured. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgp0.pgp Description: signature
Re: [SECURITY] [DSA 443-1] New xfree86 packages fix multiple vulnerabilities
Le vendredi 20 fvrier 2004 08h45 (+0100), Adrian 'Dagurashibanipal' von Bidder crivait : With the current thread in this list: thanks, Matt team - I'm quite satisfies with the way Debian handles security updates currently. I follow on this: I am more than satisfied with the security team work! This is really one of the main points which made me choose this distro. Some other ones are social-contract, philosophy, seriousness, ... And some people need to remind themselves that Debian is a volounteer project and is open source - so, if you want more/faster security updates, hire somebody to do it for you, and if you're feeling generous, allow this person to contribute his(her) efforts back to Debian. On my side, I also try to contribute to Debian (many different ways: promoting, testing, reporting, even giving free CDs sometimes, ...) and I am not paid for it, like many real Debian-Developpers, AFAIK. I think this is not about more/faster security but lack of information. I can understand information delaying. But I would greatly appreciate if I was also officially informed about this delay too! That's all! :) And once again, many thanks to the security team! My claim is only about cherry on the cake... :) -- J.C. ANDR [EMAIL PROTECTED] http://www.vn.refer.org/ Coordonnateur technique rgional / Associ technologie projet Reflets (CODA) Agence universitaire de la Francophonie (AuF) / Bureau Asie-Pacifique (BAP) Adresse postale : AUF, 21 L Thnh Tng, T.T. Hon Kim, H Ni, Vit Nam Tl. : +84 4 9331108 Fax : +84 4 8247383 Mobile : +84 91 3248747 Note personnelle : merci d'viter de m'envoyer des fichiers PowerPoint ou Word ; voir http://www.fsf.org/philosophy/no-word-attachments.fr.html signature.asc Description: Digital signature
Re: 2.2 Kernel Fix
2.2 series of kernels, sincee they're apparently vulnerable too?
You can find the patch on bugtraq/isec/etc, attached is a peek at it
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
--- linux/mm/mremap.c.security Sun Mar 25 20:31:03 2001
+++ linux/mm/mremap.c Thu Feb 19 05:10:34 2004
@@ -9,6 +9,7 @@
#include linux/shm.h
#include linux/mman.h
#include linux/swap.h
+#include linux/file.h
#include asm/uaccess.h
#include asm/pgtable.h
@@ -25,7 +26,7 @@
if (pgd_none(*pgd))
goto end;
if (pgd_bad(*pgd)) {
- printk(move_one_page: bad source pgd (%08lx)\n, pgd_val(*pgd));
+ printk(copy_one_page: bad source pgd (%08lx)\n, pgd_val(*pgd));
pgd_clear(pgd);
goto end;
}
@@ -34,7 +35,7 @@
if (pmd_none(*pmd))
goto end;
if (pmd_bad(*pmd)) {
- printk(move_one_page: bad source pmd (%08lx)\n, pmd_val(*pmd));
+ printk(copy_one_page: bad source pmd (%08lx)\n, pmd_val(*pmd));
pmd_clear(pmd);
goto end;
}
@@ -57,34 +58,22 @@
return pte;
}
-static inline int copy_one_pte(pte_t * src, pte_t * dst)
+static int copy_one_page(struct mm_struct *mm, unsigned long old_addr, unsigned long
new_addr)
{
- int error = 0;
- pte_t pte = *src;
+ pte_t * src, * dst;
- if (!pte_none(pte)) {
- error++;
- if (dst) {
- pte_clear(src);
- set_pte(dst, pte);
- error--;
+ src = get_one_pte(mm, old_addr);
+ if (src !pte_none(*src)) {
+ if ((dst = alloc_one_pte(mm, new_addr))) {
+ set_pte(dst, *src);
+ return 0;
}
+ return 1;
}
- return error;
-}
-
-static int move_one_page(struct mm_struct *mm, unsigned long old_addr, unsigned long
new_addr)
-{
- int error = 0;
- pte_t * src;
-
- src = get_one_pte(mm, old_addr);
- if (src)
- error = copy_one_pte(src, alloc_one_pte(mm, new_addr));
- return error;
+ return 0;
}
-static int move_page_tables(struct mm_struct * mm,
+static int copy_page_tables(struct mm_struct * mm,
unsigned long new_addr, unsigned long old_addr, unsigned long len)
{
unsigned long offset = len;
@@ -99,7 +88,7 @@
*/
while (offset) {
offset -= PAGE_SIZE;
- if (move_one_page(mm, old_addr + offset, new_addr + offset))
+ if (copy_one_page(mm, old_addr + offset, new_addr + offset))
goto oops_we_failed;
}
return 0;
@@ -113,8 +102,6 @@
*/
oops_we_failed:
flush_cache_range(mm, new_addr, new_addr + len);
- while ((offset += PAGE_SIZE) len)
- move_one_page(mm, new_addr + offset, old_addr + offset);
zap_page_range(mm, new_addr, len);
flush_tlb_range(mm, new_addr, new_addr + len);
return -1;
@@ -129,7 +116,9 @@
if (new_vma) {
unsigned long new_addr = get_unmapped_area(addr, new_len);
- if (new_addr !move_page_tables(current-mm, new_addr, addr,
old_len)) {
+ if (new_addr !copy_page_tables(current-mm, new_addr, addr,
old_len)) {
+ unsigned long ret;
+
*new_vma = *vma;
new_vma-vm_start = new_addr;
new_vma-vm_end = new_addr+new_len;
@@ -138,9 +127,19 @@
new_vma-vm_file-f_count++;
if (new_vma-vm_ops new_vma-vm_ops-open)
new_vma-vm_ops-open(new_vma);
+ if ((ret = do_munmap(addr, old_len))) {
+ if (new_vma-vm_ops new_vma-vm_ops-close)
+ new_vma-vm_ops-close(new_vma);
+ if (new_vma-vm_file)
+ fput(new_vma-vm_file);
+ flush_cache_range(current-mm, new_addr, new_addr +
old_len);
+ zap_page_range(current-mm, new_addr, old_len);
+ flush_tlb_range(current-mm, new_addr, new_addr +
old_len);
+ kmem_cache_free(vm_area_cachep, new_vma);
+ return ret;
+ }
insert_vm_struct(current-mm, new_vma);
merge_segments(current-mm, new_vma-vm_start,
new_vma-vm_end);
- do_munmap(addr, old_len);
current-mm-total_vm += new_len PAGE_SHIFT;
if (new_vma-vm_flags VM_LOCKED) {
current-mm-locked_vm += new_len PAGE_SHIFT;
@@ -176,9 +175,9 @@
*
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Matt Zimmerman wrote: Note the affordable, off-the-shelf. Matt, Debian is also sold on shelves. The implication being that if you pay more to a proprietary software vendor (and they typically are more expensive), then you'll be better off security-wise. If you pay someone for the increased development costs, you might be better off. From a cost perspective, it doesn't matter much if the end result is free software or not, someone has just to be willing to invest the increased effort per line of code. (Personally, I don't know of any proprietary software vendor who did this voluntarily, but some free software developers did.) Development costs of average proprietary and free software don't differ radically because the methods are pretty much the same. The huge difference lies in the way the developers try to recoup their costs, not in the costs they have to compensate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.2 Kernel Fix
On Fri, Feb 20, 2004 at 09:56:12AM +0100, Dariush Pietrzak wrote: 2.2 series of kernels, sincee they're apparently vulnerable too? You can find the patch on bugtraq/isec/etc, attached is a peek at it I had a privat discussion about this patch with someone from the Debian Security Team and he's not very happy with this patch. First it changes some printk messages wich is uncommon for sec patches. Second it changes functions which can result in kernel incompatibility. Anyway I had a kernel panic short after deploying this patch on one of my boxes here. I'm not sure if it's related to this patch but strange anyway. If you can I would advise you to wait until the OpenWall project comes up with a clean patch. Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - No sleep] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 05:58, John Galt ha scritto: we won't hide problems ... Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Shouldn't the delayed disclosure be regarded a a sort of, at least partially, infringement of the Debian manifesto ? Obviously, I'm referring to the quoted statement. Be warned that I'm not saying to avoid delaying of DSAs, I'm only interested in your opinions about compatibility between manifesto and the way security bugs are treated ( and opinions about how you can avoid the problem, if any ). Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
On Fri, Feb 20, 2004 at 12:01:13PM +0100, Gian Piero Carrubba wrote: Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Then do a web search. It's been discussed before in way too much detail and repeating the arguments just brings out the trolls. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some clarifications about the Debian-security-HOWTO
From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? Ok, sometimes the sid package may need a longer testing period, and maybe sometimes a maintainer (or the DST) can consider preferable waiting for the packaging of a new upstream release, but are these the only reasons ? Are the fixes *always* be applied to sid packages and then backported ? This method sounds a bit odd to me, especially when uploading in sid is delayed until a new upstream version is packaged. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? Ciao, Gian Piero. [1] Usually. I mean if no other problems, as dependencies or similar, arise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Matt Zimmerman [EMAIL PROTECTED] writes: On Thu, Feb 19, 2004 at 02:30:54PM +0100, Florian Weimer wrote: Bernd S. Brentrup wrote: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. begone, troll Casting a spell on him won't work either :-), he'll raise his head again next time this issue comes up. Obviously he isn't capable of accepting defeat. Debian isn't very transparent about this issue (which I consider very important), so I'm willing to help out. If read my other messages in this thread, you'll see that I'm trying to paint a more balanced picture (which is still rather bleak, but that's not my fault). I don't consider the situation to be especially bleak, considering that the alternatives are completely unworkable. I assume this is why you haven't included any in your criticism. Is it entirely impossible to have two security teams, or split the current security team into two parts? One part that patches Debian packages as soon as technically possible, and one part that follows various CERT timing requirements? I can't see how CERT would reasonable object to that model, as long as no information flow from the CERT team to the non-CERT team, and it would allow the Debian users to have access to fixes as soon as possible. I'm assuming that Debian users have suffered from delayed updates of packages, with semi-widely published exploits, because the updated Debian package is waiting for the green light from CERT. I'm not sure if this happen frequent, but it appears as if it might occur, which is reason enough to consider solutions to that problem. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Fri, Feb 20, 2004 at 01:40:23PM +0100, Simon Josefsson wrote: Is it entirely impossible to have two security teams, or split the current security team into two parts? One part that patches Debian packages as soon as technically possible, and one part that follows various CERT timing requirements? I can't see how CERT would reasonable object to that model, as long as no information flow from the CERT team to the non-CERT team, and it would allow the Debian users to have access to fixes as soon as possible. What on earth would the point of that be? If the reporting party doesn't set a release timetable then fixes are simply released once they're ready. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? The security team has nothing to do with sid packages. If a fix is ready when the advisory goes out the security team may add the sid information as a curtesy, but the lack of a sid package will in no way delay the advisory. Are the fixes *always* be applied to sid packages and then backported ? That never happens, the security HOWTO should rephrase that. I imagine that the intent is to say that sid may have a new version installed to fix a problem, but stable will get a backported patch. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Friday 20 February 2004 13.40, Simon Josefsson wrote: Is it entirely impossible to have two security teams, or split the current security team into two parts? One part that patches Debian packages as soon as technically possible, and one part that follows various CERT timing requirements? I can't see how CERT would reasonable object to that model, as long as no information flow from the CERT team to the non-CERT team, and it would allow the Debian users to have access to fixes as soon as possible. I think this is the time where I'd like to see some hard data. Which DSA's would possibly have been released differently if such a reorganisation would have been in place? For those security problems, where information goes over CERT, nothing would be different. For those security problems, where information goes not over CERT (or some similar organisation who makes a release schedules), nothing would change. So there are those where information goes out to CERT, and some non-CERT entity either finds the flaw at the same time or receives info from CERT and decides not to follow their schedule. In some cases, that entity publishes the security information to the world - and I guess CERT will then be very quick to make its own announcement, as there's no point in waiting. Nothing would change again. In other cases, that entity will publish a fix with no or incomplete information. The SSH case, I guess. The situation would not change again, as Debian cannot publish a unknown fix until it is, eh, well, known. In other cases, that entity discloses informatin only to a select few parties, amongst them the non-CERT Debian security team. This is the one case where that scheme does make a difference. Has this ever happened in the past? cheers -- vbi -- Adding manpower to a late software project makes it later. pgp0.pgp Description: signature
Re: Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 12:13, Michael Stone ha scritto: Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Then do a web search. It's been discussed before in way too much detail and repeating the arguments just brings out the trolls. You're right. I've exchanged manifesto and social contract, and my search was useless. Sorry for that. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Fri, Feb 20, 2004 at 02:34:37PM +0100, Adrian von Bidder wrote: In other cases, that entity discloses informatin only to a select few parties, amongst them the non-CERT Debian security team. This is the one case where that scheme does make a difference. Has this ever happened in the past? This has nothing to do with CERT, that's a red herring. There is *no* case where this reorganization would make a difference because a security problem that is public (e.g., reported independently by someone outside the original disclosure chain) will be immediately published regardless of whatever the original reporter's plans were. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian-security@lists.debian.org
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Fri, Feb 20, 2004 at 02:34:37PM +0100, Adrian von Bidder wrote: I think this is the time where I'd like to see some hard data. Which DSA's would possibly have been released differently if such a reorganisation would have been in place? Absolutely none. The proposed reorganization was basically to create a new security team out of thin air, not tell them about anything, and expect bugfixes sooner. It was nonsense. [misinformation about CERT deleted] In other cases, that entity will publish a fix with no or incomplete information. The SSH case, I guess. The situation would not change again, as Debian cannot publish a unknown fix until it is, eh, well, known. In other cases, that entity discloses informatin only to a select few parties, amongst them the non-CERT Debian security team. This is the one case where that scheme does make a difference. Has this ever happened in the past? CERT rarely has anything to do with coordinating disclosure, and there is no need to bring them into this discussion at all. The coordination that happens is between vendors, like Debian, as peers. Those last two cases are equivalent. Think about it. The former is entity publishes information. The latter is entity discloses information to a 'select' group of people which then turns around and publishes it. Why would anyone do that instead of publishing the information themselves? If they wanted it to be widely known, they would make it so. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. This is misleading. Security fixes for stable are prepared by the security team, while security fixes for unstable are usually prepared by the package maintainer (often by incorporating a new upstream release). Sometimes they happen at nearly the same time, and sometimes they do not. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 09:12:42PM -0700, s. keeling wrote: Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). You seem to imply that one is better off with a proprietary software vendor. I think you mis-read him Matt. Note the free or proprietary. He's saying you can go with commercial software, and fixes may take months. Or go with Open Source, and fixes may take (eg.) weeks. In either case, you will have to wait. Note the affordable, off-the-shelf. The implication being that if you pay more to a proprietary software vendor (and they typically are more expensive), then you'll be better off security-wise. Well, I've bought affordable, off-the-shelf software; my first Debian install arrived on CDs from InfoMagic (whatever happened to them?). I'm pretty sure I paid more in shipping than I paid for the disks but it was well worth it to me. This go 'round, Libranet got my money. Still well worth it. I'm still here. :-) -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: [SECURITY] [DSA 443-1] New xfree86 packages fix multiple vulnerabilities
With the current thread in this list: thanks, Matt team - I'm quite satisfies with the way Debian handles security updates currently. And some people need to remind themselves that Debian is a volounteer project and is open source - so, if you want more/faster security updates, hire somebody to do it for you, and if you're feeling generous, allow this person to contribute his(her) efforts back to Debian. On Friday 20 February 2004 07.58, Matt Zimmerman wrote: For the stable distribution (woody) these problems have been fixed in version 4.1.0-16woody3. For the unstable distribution (sid) these problems have been fixed in version 4.3.0-2. So this opens the questions - when will 4.3 hit testing? Was there recent summary? - is it worth it to upgrade now from testing? Stability? Performance? OTOH, I guess the DSA is not urgent at all as my workstations are single-user with no remote X configured. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgpLxiy3u0oRN.pgp Description: signature
Re: [SECURITY] [DSA 443-1] New xfree86 packages fix multiple vulnerabilities
Le vendredi 20 février 2004 à 08h45 (+0100), Adrian 'Dagurashibanipal' von Bidder écrivait : With the current thread in this list: thanks, Matt team - I'm quite satisfies with the way Debian handles security updates currently. I follow on this: I am more than satisfied with the security team work! This is really one of the main points which made me choose this distro. Some other ones are social-contract, philosophy, seriousness, ... And some people need to remind themselves that Debian is a volounteer project and is open source - so, if you want more/faster security updates, hire somebody to do it for you, and if you're feeling generous, allow this person to contribute his(her) efforts back to Debian. On my side, I also try to contribute to Debian (many different ways: promoting, testing, reporting, even giving free CDs sometimes, ...) and I am not paid for it, like many real Debian-Developpers, AFAIK. I think this is not about more/faster security but lack of information. I can understand information delaying. But I would greatly appreciate if I was also officially informed about this delay too! That's all! :) And once again, many thanks to the security team! My claim is only about cherry on the cake... :) -- J.C. プログフ ANDRÉ [EMAIL PROTECTED] http://www.vn.refer.org/ Coordonnateur technique régional / Associé technologie projet Reflets (CODA) Agence universitaire de la Francophonie (AuF) / Bureau Asie-Pacifique (BAP) Adresse postale : AUF, 21 Lê Thánh Tông, T.T. Hoàn Kiếm, Hà Nội, Việt Nam Tél. : +84 4 9331108 Fax : +84 4 8247383 Mobile : +84 91 3248747 ⎧ Note personnelle : merci d'éviter de m'envoyer des fichiers PowerPoint ⎫ ⎩ ou Word ; voir http://www.fsf.org/philosophy/no-word-attachments.fr.html ⎭ signature.asc Description: Digital signature
Re: 2.2 Kernel Fix
2.2 series of kernels, sincee they're apparently vulnerable too?
You can find the patch on bugtraq/isec/etc, attached is a peek at it
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
--- linux/mm/mremap.c.security Sun Mar 25 20:31:03 2001
+++ linux/mm/mremap.c Thu Feb 19 05:10:34 2004
@@ -9,6 +9,7 @@
#include linux/shm.h
#include linux/mman.h
#include linux/swap.h
+#include linux/file.h
#include asm/uaccess.h
#include asm/pgtable.h
@@ -25,7 +26,7 @@
if (pgd_none(*pgd))
goto end;
if (pgd_bad(*pgd)) {
- printk(move_one_page: bad source pgd (%08lx)\n,
pgd_val(*pgd));
+ printk(copy_one_page: bad source pgd (%08lx)\n,
pgd_val(*pgd));
pgd_clear(pgd);
goto end;
}
@@ -34,7 +35,7 @@
if (pmd_none(*pmd))
goto end;
if (pmd_bad(*pmd)) {
- printk(move_one_page: bad source pmd (%08lx)\n,
pmd_val(*pmd));
+ printk(copy_one_page: bad source pmd (%08lx)\n,
pmd_val(*pmd));
pmd_clear(pmd);
goto end;
}
@@ -57,34 +58,22 @@
return pte;
}
-static inline int copy_one_pte(pte_t * src, pte_t * dst)
+static int copy_one_page(struct mm_struct *mm, unsigned long old_addr,
unsigned long new_addr)
{
- int error = 0;
- pte_t pte = *src;
+ pte_t * src, * dst;
- if (!pte_none(pte)) {
- error++;
- if (dst) {
- pte_clear(src);
- set_pte(dst, pte);
- error--;
+ src = get_one_pte(mm, old_addr);
+ if (src !pte_none(*src)) {
+ if ((dst = alloc_one_pte(mm, new_addr))) {
+ set_pte(dst, *src);
+ return 0;
}
+ return 1;
}
- return error;
-}
-
-static int move_one_page(struct mm_struct *mm, unsigned long old_addr,
unsigned long new_addr)
-{
- int error = 0;
- pte_t * src;
-
- src = get_one_pte(mm, old_addr);
- if (src)
- error = copy_one_pte(src, alloc_one_pte(mm, new_addr));
- return error;
+ return 0;
}
-static int move_page_tables(struct mm_struct * mm,
+static int copy_page_tables(struct mm_struct * mm,
unsigned long new_addr, unsigned long old_addr, unsigned long len)
{
unsigned long offset = len;
@@ -99,7 +88,7 @@
*/
while (offset) {
offset -= PAGE_SIZE;
- if (move_one_page(mm, old_addr + offset, new_addr + offset))
+ if (copy_one_page(mm, old_addr + offset, new_addr + offset))
goto oops_we_failed;
}
return 0;
@@ -113,8 +102,6 @@
*/
oops_we_failed:
flush_cache_range(mm, new_addr, new_addr + len);
- while ((offset += PAGE_SIZE) len)
- move_one_page(mm, new_addr + offset, old_addr + offset);
zap_page_range(mm, new_addr, len);
flush_tlb_range(mm, new_addr, new_addr + len);
return -1;
@@ -129,7 +116,9 @@
if (new_vma) {
unsigned long new_addr = get_unmapped_area(addr, new_len);
- if (new_addr !move_page_tables(current-mm, new_addr, addr,
old_len)) {
+ if (new_addr !copy_page_tables(current-mm, new_addr, addr,
old_len)) {
+ unsigned long ret;
+
*new_vma = *vma;
new_vma-vm_start = new_addr;
new_vma-vm_end = new_addr+new_len;
@@ -138,9 +127,19 @@
new_vma-vm_file-f_count++;
if (new_vma-vm_ops new_vma-vm_ops-open)
new_vma-vm_ops-open(new_vma);
+ if ((ret = do_munmap(addr, old_len))) {
+ if (new_vma-vm_ops new_vma-vm_ops-close)
+ new_vma-vm_ops-close(new_vma);
+ if (new_vma-vm_file)
+ fput(new_vma-vm_file);
+ flush_cache_range(current-mm, new_addr,
new_addr + old_len);
+ zap_page_range(current-mm, new_addr, old_len);
+ flush_tlb_range(current-mm, new_addr, new_addr
+ old_len);
+ kmem_cache_free(vm_area_cachep, new_vma);
+ return ret;
+ }
insert_vm_struct(current-mm, new_vma);
merge_segments(current-mm, new_vma-vm_start,
new_vma-vm_end);
- do_munmap(addr, old_len);
current-mm-total_vm += new_len PAGE_SHIFT;
if (new_vma-vm_flags VM_LOCKED) {
current-mm-locked_vm += new_len PAGE_SHIFT;
@@ -176,9 +175,9 @@
*
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Matt Zimmerman wrote: Note the affordable, off-the-shelf. Matt, Debian is also sold on shelves. The implication being that if you pay more to a proprietary software vendor (and they typically are more expensive), then you'll be better off security-wise. If you pay someone for the increased development costs, you might be better off. From a cost perspective, it doesn't matter much if the end result is free software or not, someone has just to be willing to invest the increased effort per line of code. (Personally, I don't know of any proprietary software vendor who did this voluntarily, but some free software developers did.) Development costs of average proprietary and free software don't differ radically because the methods are pretty much the same. The huge difference lies in the way the developers try to recoup their costs, not in the costs they have to compensate.
Re: 2.2 Kernel Fix
On Fri, Feb 20, 2004 at 09:56:12AM +0100, Dariush Pietrzak wrote: 2.2 series of kernels, sincee they're apparently vulnerable too? You can find the patch on bugtraq/isec/etc, attached is a peek at it I had a privat discussion about this patch with someone from the Debian Security Team and he's not very happy with this patch. First it changes some printk messages wich is uncommon for sec patches. Second it changes functions which can result in kernel incompatibility. Anyway I had a kernel panic short after deploying this patch on one of my boxes here. I'm not sure if it's related to this patch but strange anyway. If you can I would advise you to wait until the OpenWall project comes up with a clean patch. Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - No sleep]
Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 05:58, John Galt ha scritto: we won't hide problems ... Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Shouldn't the delayed disclosure be regarded a a sort of, at least partially, infringement of the Debian manifesto ? Obviously, I'm referring to the quoted statement. Be warned that I'm not saying to avoid delaying of DSAs, I'm only interested in your opinions about compatibility between manifesto and the way security bugs are treated ( and opinions about how you can avoid the problem, if any ). Ciao, Gian Piero.
Re: Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
On Fri, Feb 20, 2004 at 12:01:13PM +0100, Gian Piero Carrubba wrote: Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Then do a web search. It's been discussed before in way too much detail and repeating the arguments just brings out the trolls. Mike Stone
Some clarifications about the Debian-security-HOWTO
From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? Ok, sometimes the sid package may need a longer testing period, and maybe sometimes a maintainer (or the DST) can consider preferable waiting for the packaging of a new upstream release, but are these the only reasons ? Are the fixes *always* be applied to sid packages and then backported ? This method sounds a bit odd to me, especially when uploading in sid is delayed until a new upstream version is packaged. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? Ciao, Gian Piero. [1] Usually. I mean if no other problems, as dependencies or similar, arise.
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Matt Zimmerman [EMAIL PROTECTED] writes: On Thu, Feb 19, 2004 at 02:30:54PM +0100, Florian Weimer wrote: Bernd S. Brentrup wrote: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. begone, troll Casting a spell on him won't work either :-), he'll raise his head again next time this issue comes up. Obviously he isn't capable of accepting defeat. Debian isn't very transparent about this issue (which I consider very important), so I'm willing to help out. If read my other messages in this thread, you'll see that I'm trying to paint a more balanced picture (which is still rather bleak, but that's not my fault). I don't consider the situation to be especially bleak, considering that the alternatives are completely unworkable. I assume this is why you haven't included any in your criticism. Is it entirely impossible to have two security teams, or split the current security team into two parts? One part that patches Debian packages as soon as technically possible, and one part that follows various CERT timing requirements? I can't see how CERT would reasonable object to that model, as long as no information flow from the CERT team to the non-CERT team, and it would allow the Debian users to have access to fixes as soon as possible. I'm assuming that Debian users have suffered from delayed updates of packages, with semi-widely published exploits, because the updated Debian package is waiting for the green light from CERT. I'm not sure if this happen frequent, but it appears as if it might occur, which is reason enough to consider solutions to that problem. Thanks.
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Fri, Feb 20, 2004 at 01:40:23PM +0100, Simon Josefsson wrote: Is it entirely impossible to have two security teams, or split the current security team into two parts? One part that patches Debian packages as soon as technically possible, and one part that follows various CERT timing requirements? I can't see how CERT would reasonable object to that model, as long as no information flow from the CERT team to the non-CERT team, and it would allow the Debian users to have access to fixes as soon as possible. What on earth would the point of that be? If the reporting party doesn't set a release timetable then fixes are simply released once they're ready. Mike Stone
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? The security team has nothing to do with sid packages. If a fix is ready when the advisory goes out the security team may add the sid information as a curtesy, but the lack of a sid package will in no way delay the advisory. Are the fixes *always* be applied to sid packages and then backported ? That never happens, the security HOWTO should rephrase that. I imagine that the intent is to say that sid may have a new version installed to fix a problem, but stable will get a backported patch. Mike Stone
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Friday 20 February 2004 13.40, Simon Josefsson wrote: Is it entirely impossible to have two security teams, or split the current security team into two parts? One part that patches Debian packages as soon as technically possible, and one part that follows various CERT timing requirements? I can't see how CERT would reasonable object to that model, as long as no information flow from the CERT team to the non-CERT team, and it would allow the Debian users to have access to fixes as soon as possible. I think this is the time where I'd like to see some hard data. Which DSA's would possibly have been released differently if such a reorganisation would have been in place? For those security problems, where information goes over CERT, nothing would be different. For those security problems, where information goes not over CERT (or some similar organisation who makes a release schedules), nothing would change. So there are those where information goes out to CERT, and some non-CERT entity either finds the flaw at the same time or receives info from CERT and decides not to follow their schedule. In some cases, that entity publishes the security information to the world - and I guess CERT will then be very quick to make its own announcement, as there's no point in waiting. Nothing would change again. In other cases, that entity will publish a fix with no or incomplete information. The SSH case, I guess. The situation would not change again, as Debian cannot publish a unknown fix until it is, eh, well, known. In other cases, that entity discloses informatin only to a select few parties, amongst them the non-CERT Debian security team. This is the one case where that scheme does make a difference. Has this ever happened in the past? cheers -- vbi -- Adding manpower to a late software project makes it later. pgppjIEffwl9y.pgp Description: signature
Re: Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 12:13, Michael Stone ha scritto: Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Then do a web search. It's been discussed before in way too much detail and repeating the arguments just brings out the trolls. You're right. I've exchanged manifesto and social contract, and my search was useless. Sorry for that. Ciao, Gian Piero.
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Fri, Feb 20, 2004 at 02:34:37PM +0100, Adrian von Bidder wrote: In other cases, that entity discloses informatin only to a select few parties, amongst them the non-CERT Debian security team. This is the one case where that scheme does make a difference. Has this ever happened in the past? This has nothing to do with CERT, that's a red herring. There is *no* case where this reorganization would make a difference because a security problem that is public (e.g., reported independently by someone outside the original disclosure chain) will be immediately published regardless of whatever the original reporter's plans were. Mike Stone
广东深圳市圣凯商贸有限责任公司
贵公司＜厂＞您好！ 本公司因进项大于销项现有余额＜增值税电脑版发票、普通商品销售发票＞可以代开。可以代寻开其它行业发票如运输发票、建筑发票、机动车发票、汽车维修发票．．。 如贵公司办有来料加工免税海关手册，因各种原因进出口数量不符，本公司可以提供符合货物进出核销，达到货物合法免税，散货搜集于各大口岸代理报关公司。代做产品的产地证。 公司可以为三资企业提供＜出口专用发票＞。 我公司愿与广大新老客户真诚合作、共谋发展。欢迎贵公司来人来电洽谈业含。 祝： 生意兴隆 财源广进 联系人：钟先生 电话：０７５５－２５０８５４６９ 传真：０７５５－２５０８５４６９ 手机：１３９２６５３００１４ 地址：广东深圳市罗湖区莲塘鹏基工业园８１６栋邮编：５１８００２
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Fri, Feb 20, 2004 at 02:34:37PM +0100, Adrian von Bidder wrote: I think this is the time where I'd like to see some hard data. Which DSA's would possibly have been released differently if such a reorganisation would have been in place? Absolutely none. The proposed reorganization was basically to create a new security team out of thin air, not tell them about anything, and expect bugfixes sooner. It was nonsense. [misinformation about CERT deleted] In other cases, that entity will publish a fix with no or incomplete information. The SSH case, I guess. The situation would not change again, as Debian cannot publish a unknown fix until it is, eh, well, known. In other cases, that entity discloses informatin only to a select few parties, amongst them the non-CERT Debian security team. This is the one case where that scheme does make a difference. Has this ever happened in the past? CERT rarely has anything to do with coordinating disclosure, and there is no need to bring them into this discussion at all. The coordination that happens is between vendors, like Debian, as peers. Those last two cases are equivalent. Think about it. The former is entity publishes information. The latter is entity discloses information to a 'select' group of people which then turns around and publishes it. Why would anyone do that instead of publishing the information themselves? If they wanted it to be widely known, they would make it so. -- - mdz
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. This is misleading. Security fixes for stable are prepared by the security team, while security fixes for unstable are usually prepared by the package maintainer (often by incorporating a new upstream release). Sometimes they happen at nearly the same time, and sometimes they do not. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. -- - mdz
