Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities
Florian Weimer writes ([SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities): DSA-2115-1 introduced a regression because it lacked a dependency on the wwwconfig-common package, leading to installations problems. This update addresses this issue. For reference, the text of the original advisory is provided below. This is the second recent regression in a security update. I'm sure you'll all agree that this is bad. It's a shame, because Debian security updates have historically had a very good reputation. Is there anything that I could do to help with improving things to avoid this happening again ? A traditional approach might be to hold a postmortem to try to find the chain of events, identify root causes, and make recommendations (whether to the Security Team or to others in the project). Has anything like that been done in this case ? Ian. offering to help - this is not a brickbat -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19635.3521.655481.658...@chiark.greenend.org.uk
Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities
On Mon, 11 Oct 2010 14:14:41 +0100, Ian Jackson wrote: Florian Weimer writes ([SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities): DSA-2115-1 introduced a regression because it lacked a dependency on the wwwconfig-common package, leading to installations problems. This update addresses this issue. For reference, the text of the original advisory is provided below. This is the second recent regression in a security update. I'm sure you'll all agree that this is bad. It's a shame, because Debian security updates have historically had a very good reputation. Is there anything that I could do to help with improving things to avoid this happening again ? A traditional approach might be to hold a postmortem to try to find the chain of events, identify root causes, and make recommendations (whether to the Security Team or to others in the project). Has anything like that been done in this case ? The problem here appears to be the jump to the new upstream version (1.8.2 to 1.8.13), which has a different dependency set. New upstreams are usually disallowed in security uploads. The question is why was that OK in this case, rather than the standard backporting approach? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101011104029.1ac6c88a.michael.s.gilb...@gmail.com
Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities
On Mon, 2010-10-11 at 10:40 -0400, Michael Gilbert wrote: The problem here appears to be the jump to the new upstream version (1.8.2 to 1.8.13), which has a different dependency set. New upstreams are usually disallowed in security uploads. The question is why was that OK in this case, rather than the standard backporting approach? Perhaps there was more to this security problem than they're telling us? Something we would need to figure out by checking upstream? The only way to find out for sure is if we forward this thread to the package maintainer and ask him to speak out about what is going on. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1286808364.18776.1.ca...@envygeeks
Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities
On Mon, 11 Oct 2010 09:46:04 -0500, Jordon Bedwell wrote: On Mon, 2010-10-11 at 10:40 -0400, Michael Gilbert wrote: The problem here appears to be the jump to the new upstream version (1.8.2 to 1.8.13), which has a different dependency set. New upstreams are usually disallowed in security uploads. The question is why was that OK in this case, rather than the standard backporting approach? Perhaps there was more to this security problem than they're telling us? I highly doubt that there is anything malicious going on here, and there is always the Debian does not hide problems mantra. The simplest, and most-likely explanation is that it was easier to update to the new upstream, rather than attempt to backport fixes for 11 separate issues. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010101548.1afb4e4c.michael.s.gilb...@gmail.com
Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities
On Mon, 2010-10-11 at 11:15 -0400, Michael Gilbert wrote: I highly doubt that there is anything malicious going on here, and there is always the Debian does not hide problems mantra. The simplest, and most-likely explanation is that it was easier to update to the new upstream, rather than attempt to backport fixes for 11 separate issues. Why assume somebody meant something malicious? I implied, that perhaps there were smaller security upgrades which would have justified a version jump... Really guy. The serious problem with you assuming I implied that something malicious is going on is the fact that we can pull the source that he uploaded to Debian directly from Debian and view it. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1286811577.22195.2.ca...@envygeeks
Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities
On Mon, 11 Oct 2010 10:39:37 -0500, Jordon Bedwell wrote: On Mon, 2010-10-11 at 11:15 -0400, Michael Gilbert wrote: I highly doubt that there is anything malicious going on here, and there is always the Debian does not hide problems mantra. The simplest, and most-likely explanation is that it was easier to update to the new upstream, rather than attempt to backport fixes for 11 separate issues. Why assume somebody meant something malicious? I implied, that perhaps there were smaller security upgrades which would have justified a version jump... Really guy. If there are smaller known security issues that were fixed in the upload but not mentioned in the DSA, which there aren't, then that would be a case of hiding problems. The implication there would be that security team members are intentionally hiding info about issues, which they aren't. However, if that were happening, the only way to interpret that would be as malicious. The serious problem with you assuming I implied that something malicious is going on is the fact that we can pull the source that he uploaded to Debian directly from Debian and view it. OK, so do that before making an unfounded claim that there is more to the issue than you're being told. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101011120415.f21cbba1.michael.s.gilb...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On 10/10/2010 12:40 PM, Kees Cook wrote: On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. Anyone else perceive this situation as being a bit sub-optimal from the security perspective? I'm quite certain there are lots of Debian server admins out there who had assumed that in the year 2010 their operating system is not going to disable the nonexecutable page protection which is built into every modern processor. Yes, I have always thought that PAE in general was a kludge, but the NX bit is now a fundamental part of the process integrity provided by the CPU. It's been available in the 2.6 kernel, and shipped in MS Windows, since 2004. What can be done to not disable page protections in the default kernel? What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? - Marsh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb3406e.5020...@extendedsubset.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
In 4cb3406e.5020...@extendedsubset.com, Marsh Ray wrote: On 10/10/2010 12:40 PM, Kees Cook wrote: On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. Anyone else perceive this situation as being a bit sub-optimal from the security perspective? No. I'm quite certain there are lots of Debian server admins out there who had assumed that in the year 2010 their operating system is not going to disable the nonexecutable page protection which is built into every modern processor. Debian server admins are running amd64, not i386, and NX is supported by default on 64-bit kernels. Even if they are running the i386 arch because of some random closed app they have to have on top of Debian, they can run the amd64 kernel. Yes, I have always thought that PAE in general was a kludge, but the NX bit is now a fundamental part of the process integrity provided by the CPU. It's been available in the 2.6 kernel, and shipped in MS Windows, since 2004. MS Windows also defaults to PAE. What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Mon, 11 Oct 2010 11:50:54 -0500, Marsh Ray wrote: On 10/10/2010 12:40 PM, Kees Cook wrote: On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. Anyone else perceive this situation as being a bit sub-optimal from the security perspective? I agree that this is not ideal. I'm quite certain there are lots of Debian server admins out there who had assumed that in the year 2010 their operating system is not going to disable the nonexecutable page protection which is built into every modern processor. Yes, I have always thought that PAE in general was a kludge, but the NX bit is now a fundamental part of the process integrity provided by the CPU. It's been available in the 2.6 kernel, and shipped in MS Windows, since 2004. What can be done to not disable page protections in the default kernel? You would need to convince the kernel team that the bigmem kernel should be the default on i386 systems. What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? There is the checksec script, which I have packaged, but have yet to get sponsored. It checks whether various kernel security features are enabled. Other than that, perhaps a debconf warning on kernels without NX enabled would be useful. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101011134514.0826e6bb.michael.s.gilb...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On 10/11/2010 12:21 PM, Boyd Stephen Smith Jr. wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? No. Interesting. Do you happen to run any such systems in a production environment? Debian server admins are running amd64, not i386, and NX is supported by default on 64-bit kernels. Even if they are running the i386 arch because of some random closed app they have to have on top of Debian, they can run the amd64 kernel. Oh good. Then I'm glad I didn't notify those admins I know who bought expensive IBM servers just a couple of years ago that turned out to have virtualization support for 64-bit guests disabled in the BIOS even though the Intel Xeon CPUs had support for it. They were already disappointed that they couldn't use weren't getting all the features of the processors and they would be just heartbroken to find out that they'd been pwned through executable stacks too. MS Windows also defaults to PAE. So from this we can conclude it doesn't adversely affect consuming content (i.e. watching television) and playing 3D games, which is probably actually telling us something about PAE's effect on kernel task-switch latencies. FWIW, Microsoft also used to have separate single and multi-CPU kernels, but these days prefers to support a single kernel image. Didn't Debian begin installing SMP by default a while back too? What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. That's my understanding too. I was really asking about the default. How bad is PAE really? These guys: http://people.redhat.com/nmurray/RHEL-2.1-VM-whitepaper.pdf seem to say when they tested it worked out to about 1% overhead. My guess is the kind of sites that would find that significant are probably tuning their own kernels. Most of us would prefer the 1% performance hit over having an executable stack (and heap). On 10/11/2010 12:45 PM, Michael Gilbert wrote: On Mon, 11 Oct 2010 11:50:54 -0500, Marsh Ray wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? I agree that this is not ideal. Thank you, I'm not totally off the wall then (at least not in this specific way). What can be done to not disable page protections in the default kernel? You would need to convince the kernel team that the bigmem kernel should be the default on i386 systems. Please? What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? There is the checksec script, which I have packaged, but have yet to get sponsored. It checks whether various kernel security features are enabled. That sounds useful. Do you have a link? Other than that, perhaps a debconf warning on kernels without NX enabled would be useful. I've sure seen less valuable warnings. - Marsh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb38d3a.1040...@extendedsubset.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Mon, 11 Oct 2010 17:18:34 -0500 Marsh Ray wrote: You would need to convince the kernel team that the bigmem kernel should be the default on i386 systems. Please? Don't ask this list, ask the kernel team (via bug report and/or mailing list message). Note that ubuntu uses some kind of NX emulation on i386 when its disabled in the bios or unsupported on the cpu, which may be an option as well here. A patch for that submitted as a kernel bug would be most effective. What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? There is the checksec script, which I have packaged, but have yet to get sponsored. It checks whether various kernel security features are enabled. That sounds useful. Do you have a link? http://trapkit.de/tools/checksec.html Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101011192429.ad97c225.michael.s.gilb...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Monday, October 11, 2010 17:18:34 you wrote: On 10/11/2010 12:21 PM, Boyd Stephen Smith Jr. wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? No. Interesting. Do you happen to run any such systems in a production environment? Depends on what you mean by production. I do manage http://www.freegeekarkansas.org, http://www.iguanasuicide.net, and the MX for iguanasuicide.net. It's only 3 systems.[1] All are VPSes, 2 running Debian Lenny; 1 running Ubuntu 10.04 LTS. Debian server admins are running amd64, not i386, and NX is supported by default on 64-bit kernels. Even if they are running the i386 arch because of some random closed app they have to have on top of Debian, they can run the amd64 kernel. Oh good. Then I'm glad I didn't notify those admins I know who bought expensive IBM servers just a couple of years ago that turned out to have virtualization support for 64-bit guests disabled in the BIOS even though the Intel Xeon CPUs had support for it. They were already disappointed that they couldn't use weren't getting all the features of the processors and they would be just heartbroken to find out that they'd been pwned through executable stacks too. 1. Configure the BIOS properly. 2. If that's not possible, hack the BIOS. 3. If that's too hard, use LinuxBIOS / OpenBoot. Finally, don't whine when your software doesn't correct for intentional hardware crippling. Also: -bigmem is available. What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. That's my understanding too. I was really asking about the default. Most of us would prefer the 1% performance hit over having an executable stack (and heap). Then install -bigmem, reboot and be done. Remember that Debian i386 targets more than beefy servers. In fact, it probably has a larger install base on Atom-based router boards, All-in-one PCs, and netbooks. That said, I don't really care what the default is for i386. When multiple kernels are available for my architecture, I do the research and install the correct one. [1] One of the systems in that configuration is not directly public facing; it handles the ClamAV scanning via a private network for the MX. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
RECEVEZ UN CHEQUE DE 180 € et 30 % d'économies sur vos dépenses de santé.
Cette newsletter vous a été envoyée au format graphique HTML. Si vous lisez cette version, alors votre logiciel de messagerie préfère les e-mails au format texte. Vous pouvez lire la version originale en ligne: http://ymlp176.com/zc33LD Conformément à la loi «Informatique et Libertés» du 6 janvier 1978, vous disposez d'un droit d'accès, de rectification et d'opposition, aux informations qui vous concernent. Vous pouvez exercer ce droit auprès de l'émetteur en répondant directement à cet email. Vous pouvez également obtenir à cette adresse des informations concernant les transferts de données mentionnés ci-dessus. Si vous ne souhaitez pas recevoir des propositions commerciales de notre part ou de nos partenaires par voie électronique, merci de procéder à votre désinscription. Si vous ne désirez plus recevoir de courrier de notre part : désabonnez-vous Pour être sûr(e) de recevoir nos prochaines newsletters, merci d'ajouter l'adresse suivante : cont...@expressmut.com dans votre carnet d'adresses. Conformément à la loi «Informatique et Libertés» du 6 janvier 1978, vous disposez d'un droit d'accès, de rectification et d'opposition, aux informations qui vous concernent. Vous pouvez exercer ce droit auprès de l'émetteur en répondant directement à cet email. Vous pouvez également obtenir à cette adresse des informations concernant les transferts de données mentionnés ci-dessus. Si vous ne souhaitez pas recevoir des propositions commerciales de notre part ou de nos partenaires par voie électronique, merci de procéder à votre désinscription. Pour être sûr(e) de recevoir nos prochaines newsletters, merci d'ajouter l'adresse suivante : newslet...@maboutiqueephemere.com dans votre carnet d'adresses. Merci de ne pas répondre à cet email. _ Désinscription à la newsletter: http://ymlp176.com/u.php?id=gesyjujgsgjjquyjgjsuw Powered par YourMailingListProvider
Confirmation de désabonnement de notre base
Bonjour, Ceci est une confirmation que vous vous êtes désabonné de notre base. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/31086d433c06273ea9bea4a96281a...@smtp.ymlp33.net
