Re: amd64 running on Intel Celeron and Pentium?
On Sun, Apr 17, 2022 at 10:05:39AM +0200, Friedhelm Waitzmann wrote: vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.00GHz stepping : 4 cpu MHz : 1993.656 cache size : 512 KB ? Celeron 440 for sure is 64-bit. Pentium 4 2.00 GHz I am not sure, there are many models and variations of this processor. Is it socket LGA775 also? It is a Willamette on a socket 423. Nope, that would be model 1; model 2 was northwood. It's much easier to look at the family/model than trying to guess based on the marketing name. https://ark.intel.com/content/www/us/en/ark/products/27433/intel-pentium-4-processor-2-00-ghz-512k-cache-400-mhz-fsb.html
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Thu, Apr 14, 2022 at 02:34:22PM +0200, Elmar Stellnberger wrote: On Wed, Apr 13, 2022 at 03:11:04PM -0400, Michael Stone wrote: On Wed, Apr 13, 2022 at 08:18:30PM +0200, Levis Yarema wrote: > What about Spectre /Meltdown? P3/P4/Pentium M systems don´t have that? Core 2 > systems to my knowledge can. There's no reason to believe netburst systems are not affected by any of the cpu issues identified in the past few years, but they are obsolete and unsupported so nobody is making official statements about them. These systems also lack a number of security features present in modern CPUs; picking an ancient chip for "security reasons" is likely misguided. Also, in the context of this thread, note that the most recent Core 2 processor was released in 2010. AFAIK there is just no official statement of Intel about Pentium III, IV and M CPUs. That may also be because they want(ed) people to buy newer machines. Nonetheless I would be in wonder if nobody at all had ever tested these CPUs for Spectre and Meltdown. The issue itself wasn´t discovered by Intel either. There's a general class of problems related to how CPUs handle various checks while executing out of order or speculative instructions. The specifics of how to exploit the vulnerabilities varies in different CPU implementations, and new techniques are identified pretty regularly. Previous-gen atom processors weren't affected by most of this because they were strictly in-order. (Intel still supports those, and has issued "not vulnerable" statements for many of the CPU problems.) The netburst (pentium 4) architecture, by contrast, was out-of-order and had a huge pipeline (some even supported hyperthreading, which has been a whole bag of problems in itself.) It's really hard to believe that intel managed to get everything right 25 years ago in netburst and then just forgot how to do it with later generations. More plausibly, nobody is spending a lot of time researching how to exploit flaws in an architecture that is functionally obsolete. There's been a lot of wild speculation that Pentium 4 was some kind of high point for "secure" CPUs, but that's coming from internet pontificators rather than serious researchers.
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Wed, Apr 13, 2022 at 08:18:30PM +0200, Levis Yarema wrote: What about Spectre /Meltdown? P3/P4/Pentium M systems don´t have that? Core 2 systems to my knowledge can. There's no reason to believe netburst systems are not affected by any of the cpu issues identified in the past few years, but they are obsolete and unsupported so nobody is making official statements about them. These systems also lack a number of security features present in modern CPUs; picking an ancient chip for "security reasons" is likely misguided. Also, in the context of this thread, note that the most recent Core 2 processor was released in 2010.
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Wed, Apr 13, 2022 at 07:18:53PM +0200, Levis Yarema wrote: If I would get an x64 CPU from a Linux pro, sure I would take it. Otherwise I would not recommend to just take any old hardware for exchange with my working one since not all of it was easily well supported by Linux these days, as far as I can remember. 10 year old hardware is generally not a problem. You might have abysmal video performance, but so does anything with 20 year old hardware. In the worst case, if it doesn't work, pick different 10 year old hardware.
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Wed, Apr 13, 2022 at 05:32:10PM +0200, Odo Poppinger wrote: I have a beloved P4 Gericom Frontman and I do not want to give it away. and that's fine, but it's increasingly unreasonable to try to run a modern general purpose OS on hardware that's 20 years old. if the driver is nostalgia, something like freedos may be a better fit, or something like netbsd that makes support for obscure hardware a goal, or just sticking with the original OS. running a suitably stripped-down debian install is possible, but enough work that it's just not the best tool for the job.
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Wed, Apr 13, 2022 at 03:44:00PM +0100, piorunz wrote: On 12/04/2022 04:59, Friedhelm Waitzmann wrote: You mean, that it is possible to run amd64 on my old hardware 1# vendor_id : GenuineIntel cpu family : 6 model : 22 model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz stepping : 1 microcode : 0x43 cpu MHz : 1229.629 cache size : 512 KB and 2# vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.00GHz stepping : 4 cpu MHz : 1993.656 cache size : 512 KB ? And if it is indeed possible, how can I switch from i386 to amd64? Can this be done with the apt tools? Then during the migrating some packages will be from amd64 already while others will be still i386. How does that go right? Celeron 440 for sure is 64-bit. Pentium 4 2.00 GHz I am not sure, there are many models and variations of this processor. Is it socket LGA775 also? family 15 model 2 is northwood based. no amd64. the best option for that one is to find a cheap second hand box with a CPU that's only 10 years old instead of (literally) 20 years old and retire it; those old p4's were really power hungry, and it shouldn't be hard to find a replacement for a cost (maybe even free) that will pay for itself in electricity savings alone.
Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?
On Wed, Jan 13, 2021 at 09:49:43PM +0100, Christoph Pflügler wrote: [ 0.00] microcode: microcode updated early to revision 0xd6, date = 2019-10-03 [ 0.379026] SRBDS: Vulnerable: No microcode [ 1.625090] microcode: sig=0x506e3, pf=0x2, revision=0xd6 [ 1.625215] microcode: Microcode Update Driver: v2.2. Seems like the microcode is applied to my CPUs. This is also supported by numerous other CVEs getting mitigated after intel-microcode installation. That's exactly the same signature I was testing with different results: microcode: sig=0x506e3, pf=0x2, revision=0xd6 The only way I can get your results is to run unprivileged, but you said you weren't doing that. The checks for 3640 and 3615 are basically just looking for SSBD; in the top section the line that says "CPU indicates SSBD capability" presumably says something other than "YES (Intel SSBD)"? I also tried the latest meltdown-spectre-checker (v0.44), the results are the same (plus another red 2020 CVE). This is presumably CVE-2020-0543; if you look at the changelog for intel-microcode it discusses that issue. You can install the backports version which should fix that at the risk of a boot failure.
Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?
On Tue, Jan 12, 2021 at 05:25:23PM +0100, Giacomo Catenazzi wrote: In any case, according Intel, microcode should be updated by BIOS I wonder if anyone from intel can manage to say that with a straight face.
Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?
On Fri, Jan 08, 2021 at 10:48:30PM +0100, Christoph Pflügler wrote: On 08.01.21 22:34, Michael Stone wrote: On Fri, Jan 08, 2021 at 09:12:53PM +0100, Christoph Pflügler wrote: Installing package intel-microcode in Debian 10 (Buster) mitigates most vulnerabilities as per spectre-meltdown-checker. However, CVE-2018-3640 and CVE-2018-3615 are still displayed as unmitigated after reboot, with spectre-meltdown-checker --explain (executed as su) pointing to missing microcode upgrades. According to the Debian package description of intel-microcode, the two vulnerabilities are fixed in the current version of the package. This occurs in exactly the same way on two different machines, one with an i5-3320M CPU and another one with an E3-1235L v5. If I remember correctly, I was all green as per spectre-meltdown-checker in Debian 9 (Stretch). What version of intel-microcode do you have installed? intel-microcode:amd64/buster 3.20200616.1~deb10u1 uptodate, installed from Debian non-free repository With an E3 v5, linux 4.19.0-13, and intel-microcode 3.20200616.1 the checker reports green for those checks on my test system. Do you have the latest spectre-meltdown-checker, and are you running it as root? If I run the current version as an unprivileged user those checks come up red (presumably because it can't read the cpu registers it is trying to read).
Re: intel-microcode not fixing CVE-2018-3640, CVE-2018-3615 on Debian 10?
On Fri, Jan 08, 2021 at 09:12:53PM +0100, Christoph Pflügler wrote: Installing package intel-microcode in Debian 10 (Buster) mitigates most vulnerabilities as per spectre-meltdown-checker. However, CVE-2018-3640 and CVE-2018-3615 are still displayed as unmitigated after reboot, with spectre-meltdown-checker --explain (executed as su) pointing to missing microcode upgrades. According to the Debian package description of intel-microcode, the two vulnerabilities are fixed in the current version of the package. This occurs in exactly the same way on two different machines, one with an i5-3320M CPU and another one with an E3-1235L v5. If I remember correctly, I was all green as per spectre-meltdown-checker in Debian 9 (Stretch). What version of intel-microcode do you have installed?
Re: Intel Microcode updates
On Tue, Jun 11, 2019 at 08:00:49PM +0200, Davide Prina wrote: On 10/06/19 20:31, Michael Stone wrote: On Mon, Jun 10, 2019 at 07:46:47PM +0200, Davide Prina wrote: On 10/06/19 13:16, Michael Stone wrote: Your CPU is not supported my Intel, so you either accept the risk or buy a new one. you have another choice: disable the SMP & C. and all mitigation form Linux That's not correct, but will set your performance back 20 years. why is it not correct? I have read that most of this hardware bug is related to the execution of the possible future operation, while the system is executing the actual operation. OK this solution will slow down a lot your CPU. It's simply not correct that every one of these hardware bugs can be mitigated by running on only a single thread. I think you're confusing SMP (multiple processors) with speculative execution (within a processor), but this really isn't the right forum to sort that out. * you will get only mitigation and not bug correction. Mitigation == the attack is more hard, but it can be done successfully. I don't have That is also not correct. why? Because "mitigation" simply does not mean "the attack...can be done successfully". In some cases the mitigations make an attack unlikely, in other cases the mitigations change the behavior of the system to make an attack impossible, and in some cases the mitigations add capabilities which can be used to prevent attacks but which require additional changes in programs. * your CPU run slower because of these mitigation (I have rad that for some task you can have 50% or less performance), That depends on the CPU, some see significant impacts, others see none or were never vulnerable to some of these issues. that true, but I never read that a processor type with a spectre/meltdown/& C. have been released with a new CPU version that is immune to this bug, so you always need this software mitigation. "etc" covers a lot of ground when we're talking about (currently) 12 seperately-identified vulnerabilities. Many CPUs weren't vulnerable to every one of the vulnerabilities. Getting one not vulnerable to the vulnerabilities that are most expensive to mitigate is a good starting place. Some have functionality that makes the mitigations less expensive than others. Again, this isn't the right place to tell people what CPU to buy or to discuss the performance characteristics of more than half a dozen different CPU families. As a specific example, AMD processors were not vulnerable to the "meltdown" bug. As a further specific example, some vulnerable intel CPUs support the PCID instructions which make the mitigation much less expensive by allowing the kernel to selectively flush the TLB rather than flushing the whole thing. So just for that one vulnerability the cost ranges from "nothing/not vulnerable" to "modest" to "severe"--though the cost is also heavily dependent on the workload and whether a single user thread does most of the work or whether there are frequent system calls or contention on the system. There's enough misinformation about this class of attacks without spreading more... I have try to read the research that describe those hardware bugs, probably I don't have understand all or I don't have read all the document Then it's probably best that you not tell thousands of people the wrong information.
Re: Intel Microcode updates
On Mon, Jun 10, 2019 at 07:46:47PM +0200, Davide Prina wrote: On 10/06/19 13:16, Michael Stone wrote: Your CPU is not supported my Intel, so you either accept the risk or buy a new one. you have another choice: disable the SMP & C. and all mitigation form Linux That's not correct, but will set your performance back 20 years. * you will get only mitigation and not bug correction. Mitigation == the attack is more hard, but it can be done successfully. I don't have That is also not correct. * your CPU run slower because of these mitigation (I have rad that for some task you can have 50% or less performance), That depends on the CPU, some see significant impacts, others see none or were never vulnerable to some of these issues. There's enough misinformation about this class of attacks without spreading more... * new hardware bugs and variant of previous bugs are found constantly, so we need a new CPU class designed for security. I have read that some people want to create a new CPU under free license, I think that is the only solution that we can trust For those who want to use a computer now, that's not particularly helpful.
Re: Intel Microcode updates
On Mon, Jun 10, 2019 at 02:01:25PM +1000, Russell Coker wrote: I just discovered the spectre-meltdown-checker package (thanks Sylvestre for packaging this). model name : Intel(R) Core(TM)2 Quad CPUQ9505 @ 2.83GHz On a system with the above CPU running Debian/Testing I get the following results from the spectre-meltdown-checker script. Is this a bug in the intel- microcode package that the latest version isn't packaged? There is no newer version of intel-microcode in Unstable. # spectre-meltdown-checker |grep CPU.mic * Hardware support (CPU microcode) for mitigation techniques * CPU microcode is known to cause stability problems: NO (model 0x17 family 0x6 stepping 0xa ucode 0xa0b cpuid 0x1067a) * CPU microcode is the latest known available version: NO (latest version is 0xa0e dated 2015/07/29 according to builtin MCExtractor DB v111 - 2019/05/18) IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it * CPU microcode mitigates the vulnerability: NO STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability) * CPU microcode mitigates the vulnerability: N/A Your CPU is not supported my Intel, so you either accept the risk or buy a new one. (Note that the latest version of the microcode is from 2015--long before any of these speculative execution vulnerabilities were mitigated.) Yours is a yorkfield: https://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/
Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?
On Thu, Oct 13, 2016 at 02:45:29PM -, te3...@sigaint.org wrote: As you asked me for a specific case, may I bring up CVE-2016-5696. A fix to the medium-risk vulnerability was uploaded on July 10, 2016 by Eric Dumazet (cf. https://github.com/torvalds/linux/commit/75ff39ccc1bd5d3c455b6822ab09e533c551f758) Ben Hutchings uploaded his work on the fix on August 12, 2016 (cf. https://anonscm.debian.org/cgit/kernel/linux.git/log/?h=jessie-security) Debian officially pushed out the fix on September 4, 2016 via DSA-3659-1. Are there reasons for the 23-day delay in providing end-users the patch? I don't know the specifics of this one but kernel updates are generally kind of a mess and in this case we're talking about an issue that basically boils down to a DoS for internet-facing hosts and for which there existed a mitigation. I'm personally not too concerned about the timeline. Mike Stone
Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?
On Wed, Oct 12, 2016 at 10:43:41AM -, te3...@sigaint.org wrote: 1. If I understood correctly the contents of your reply, on what basis does the Debian security team assess the severity of each security vulnerability? What are those criteria? You'll find that there's a lot of criticism of CVSS in the industry, and that a real CVSS number depends heavily on temporal and environmental factors which aren't reflected in the NVD baseline. It's not particularly uncommon for base scores to be overinflated given configuration specifics, or to understate the importance of vulnerabilities being actively exploited. Relying soley on base scores to prioritize actions without considering the environmental or temporal factors is a mistake per the guidelines on how to use CVSS. 2. Your latest reply implies strongly the possibility of the Debian security team's assessments of security vulnerabilities differing from those of the security teams of other popular Linux distros such as Gentoo, Kali, ArchLinux, Ubuntu, etc. Am I correct? You'll find that no vendor uses CVSS base scores in NVD to strictly prioritize their work. As an example, ArchLinux issues a patch for a security vulnerability CVE-2016-xyz with an NVD rating of medium risk. However the Debian security team does not issue a fix for it. To have an example, you'd need specifics. This is a hypothetical without a question. If the implicit question is "could this happen" the answer is yes, but you'd need to discuss a specific case to find out why. Mike Stone
Re: httpoxy efforts? (and is it "much" more than just HTTP_PROXY?)
On Wed, Jul 20, 2016 at 03:27:56PM +0200, Christoph Anton Mitterer wrote: If had a small mail conversion with Dominic Scheirlinck (one of the "original" people discovering that issue), and in principle he seemed to confirm that the above could happen, while of course it's less likely than with http_proxy which has been some kind of semi-standard for years now. The funny thing is that the standard was for http_proxy to be lower case. People "fixed it" to allow the upper case version in some programs... Mike Stone
Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?
On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote: BoringSSL is also free software, as long as there are maintainers who are willing to spend time on it, I think it has rights to exist in Debian. Well I have been contributing to Debian for not long, so please point me out my mistakes. :) The question is, "who does the security updates for the package 5 years from now". As a general rule, we don't allow private embedded copies of libraries because then a security update for a library means chasing down and fixing any number of copies. (In historic terms, this was a huge issue, for example, with zlib bugs.) On top of that, if the upstream says flat-out that it's an unstable API, putting it into a debian release seems like a bad idea. Putting it unstable and never letting it make it to stable is a possibility, but the point of unstable is to eventually get packages into a released version so that seems somewhat an abuse of the system. If it's really a standalone component that's expected to change a lot and not interact with anything else in debian, then putting it in an external repository seems like a better fit. Mike Stone
Re: [SECURITY] [DSA 3547-1] imagemagick security update
On Tue, Apr 12, 2016 at 08:56:35PM -0300, Henrique de Moraes Holschuh wrote: Then, maybe we should consider a better way to deal with areas where you get only one choice out of geoip? Reach out to the relevant team outlining your issues (e.g., lack of IPv6 connectivity)? Advising people to hard code security mirrors isn't the right solution. Mike Stone
Re: [SECURITY] [DSA 3547-1] imagemagick security update
On Tue, Apr 12, 2016 at 04:19:20PM -0300, Henrique de Moraes Holschuh wrote: We don't disclose which mirrors are members of the security.debian.org pool anywhere (that I could find), so we are currently hiding everything behind security.debian.org. This wasn't a problem when a DNS lookup for security.debian.org would return a RR-SET with several A and records, but geo-ip changed that to return a single A record. When geo-ip points security.debian.org to a broken or stale mirror for someone, it is a pain to work around it for the duration. And if you need to access security.debian.org over IPv6, "too bad". Huh? Huh? host security.debian.org security.debian.org has address 149.20.20.19 security.debian.org has address 128.61.240.73 security.debian.org has address 128.101.240.215 security.debian.org has address 128.31.0.63 security.debian.org has IPv6 address 2607:ea00:101:3c0b::1deb:215 security.debian.org has IPv6 address 2001:4f8:8:36::1deb:19 security.debian.org has IPv6 address 2610:148:1f10:3::73 Mike Stone
Re: tracking security issues without CVEs
On Wed, Mar 23, 2016 at 10:59:34AM +0800, Paul Wise wrote: I think Debian needs to go towards the approach of VRDX-SIG and do identifier cross-referencing instead of settling on *one* system for referring to security vulnerabilities. Internally, we would continue to use CVEs and CVE-2016- for issues without CVEs and then map all the external identifiers onto those. I think debian should pick a common one to use by default, and use a different one only if necessary. I think trying to turn into yet another clearinghouse of cross-referenced vulnerability IDs is a bottomless pit of wasted effort. Mike Stone
Re: [SECURITY] [DSA 3481-1] glibc security update
On Wed, Feb 17, 2016 at 10:58:01AM +0100, Jan Lühr wrote: Comparing the age (2015-07) and the severity: Can you give some details on the situation? Why was the bug fixed so late? https://sourceware.org/bugzilla/show_bug.cgi?id=18665 Mike Stone
Re: Logjam mitigation for Wheezy?
On Tue, Jun 02, 2015 at 02:01:47PM +, Thorsten Glaser wrote: Michael Stone debian.org> writes: You can mitigate it right now by reconfiguring your server to remove DH ciphers from SSLCipherSuite. That’s throwing the baby out with the bathwater and removing the ability to use PFS with clients that do not use ECC, for whatever reason (any discussing these reasons is off-topic). So, no. Bad advice, actually, which should not be given. That's really something you need to evaluate for yourself. If you've got a reason not to use ECDH and still want PFS then you'll have to do something else. If you're happy to use ECDH and don't care about clients that can't support that, then turning off DH could be a reasonable mitigation. From a practical risk management perspective, even in the face of a threat model that involves attacking crypto, I'd be more worried about the vulnerabilities of something that's so old that it doesn't do ECDH than I'd be about any quibbles over DH vs RSA. If your concern is simply about the security of ECDH then this goes back to "evaluate for yourself". Hopefully someone considers all the pros and cons of whatever crypto configuration they're using. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c65bb9cc-0930-11e5-9b6a-00163eeb5...@msgid.mathom.us
Re: Logjam mitigation for Wheezy?
On Wed, May 20, 2015 at 12:47:35PM -0400, Dan Ritter wrote: Is there any chance of getting Logjam ( https://weakdh.org/ ) mitigation for Wheezy packages? You can mitigate it right now by reconfiguring your server to remove DH ciphers from SSLCipherSuite. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8c546854-ff18-11e4-9b6a-00163eeb5...@msgid.mathom.us
Re: Should we be alarmed at our state of security support?
On Thu, Feb 19, 2015 at 07:29:29AM -0600, John Goerzen wrote: However, part of what I was trying to figure out here is: do we have a lot of unpatched vulnerabilities in our archive? Yes. Every system (not just debian) has unpatched vulnerabilities. In some cases those vulnerabilities are known, and in some cases those vulnerabilities are unknown. Fixing all of the vulnerabilities in general purpose software is effectively impossible. So the real question is, are there unfixed vulnerabilities worth fixing? The answer to that depends on the level of risk one is willing to take, and may include patching only vulnerabilities that are likely to be exploited, applying all potentially security-related patches, or intensively auditing the code and trying to fix all vulnerabilities. The question is made more difficult by the fact that applying patches can introduce new vulnerabilities--so fixing all low-risk vulnerabilities could potentially make things worse rather than better. There are no good answers, and the better answers all require a great deal of effort. Debian may be able to do a better job of communicating why certain bugs are prioritized over others, but what really should matter to you is whether the assumptions used to prioritize each bug are valid for your particular environment. (That is, you need to review each bug at length.) For most people that level of effort isn't justified, and they are content to accept whatever is prioritized by their vendor. If there are specific cases where you think that the debian made the wrong call, it's reasonable to bring those up for discussion--people do make mistakes. But do understand that we will never get to zero bugs. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a6179694-b841-11e4-8442-00163eeb5...@msgid.mathom.us
Re: [SECURITY] [DSA 3148-1] chromium-browser end of life
On Thu, Feb 05, 2015 at 09:38:11AM +0100, Paul van der Vlis wrote: Op 05-02-15 om 00:54 schreef Holger Levsen: and then finally, sometime later in 2014, security support for oldstable was finally introduced for the first time. There was always a year security support for oldstable (sometimes with some remarks in te release notes for Mozilla products). That's not actually true. Prior to potato, security supported ended pretty much immediately upon the next release. With potato the security team pointed out vulnerabilities that affected slink for a few months, but I don't recall that any packages were built. Potato was the first release I'm sure got packages after its successor was released, and I remember the security team trying to figure out how long to keep that up. https://lists.debian.org/debian-devel-announce/2002/11/msg1.html Note the reference to having done so for a whole three months. :) I don't think it went a full year, and I don't think it was clearly communicated when the team finally threw in the towel. Woody was the first release, I think, that got a full year of security updates. So that's almost 10 years, but only 5 releases. And "full year" always was best effort, and there were some packages that just didn't make it. Communication of that has varied, sometimes it was clear and sometimes not. What changed in 2014 was an attempt to support for more than one year. The process of actually building security updates has gotten a lot easier, which made support more practical; I think the current security team doesn't spend much time finding machines to build things, the way things were done 15 years ago--but it will always be a lot of work backporting pactches to code that upstream stopped supporting years earlier. At some point, security updates for old releases is more a fig leaf than reality: nobody puts as much effort into finding problems with obsolete code as current code, so only the really obvious problems will get fixed. And another reality is that even for the obvious problems if the fix is too hard it'll get kicked down the road and not get done before the end of LTS. (Not a criticism of the debian LTS team, more an observation of LTS for both commercial and free projects over the decades.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150205133704.gj31...@mathom.us
Re: https://wiki.debian.org/LTS/Using => broken?
[I suggested using ftp.us.debian.org rather than http.debian.net because of problems with squeeze-lts on the latter] On Thu, Feb 05, 2015 at 01:57:34PM +0100, Ml Ml wrote: Looks good! Who can report this? :) CC'd the http.debian.net maintainer. Jens, you wrote the original wiki page, is there a reason it specifies http.debian.net rather than a debian.org resource? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150205133508.gi31...@mathom.us
Re: https://wiki.debian.org/LTS/Using => broken?
On Thu, Feb 05, 2015 at 01:34:36PM +0100, Ml Ml wrote: can anyone confirm this?: # cat /etc/apt/sources.list deb http://http.debian.net/debian/ squeeze main contrib non-free deb-src http://http.debian.net/debian/ squeeze main contrib non-free deb http://http.debian.net/debian squeeze-lts main contrib non-free deb-src http://http.debian.net/debian squeeze-lts main contrib non-free Do you have the same problem if you use http://ftp.us.debian.org rather than http://http.debian.net? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4fa8dfbe-ad35-11e4-89c3-00163eeb5...@msgid.mathom.us
Re: [SECURITY] [DSA 3032-1] bash security update
On Thu, Sep 25, 2014 at 10:54:38AM -0300, Henrique de Moraes Holschuh wrote: I suggest everyone to do a spring cleanup in the login shells for system accounts, and to deploy mitigation. In general it's a good idea to have /bin/sh point to something other than bash. That's the default on current debian systems, but might not be the case on systems which were upgraded. Use dpkg-reconfigure dash to change that. There are still cases where the login shell will come into play, but the biggest worms crawling around are leveraging /bin/sh. Note that if you've been running /bin/sh as bash, you may find local scripts which depend on bashisms--you'll want to test this, and it may not be the best thing to do in a panic right now. But definitely consider it for the long term. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7cac97c6-44bc-11e4-8968-00163eeb5...@msgid.mathom.us
Re: Checking for services to be restarted on a default Debian installation
On Wed, Sep 03, 2014 at 11:34:46AM -0700, Jameson Graef Rollins wrote: Is 20MB really a lot? That seems like essentially nothing to me nowadays. I'm in the middle of a 2.2GB upgrade right now. It sure is for people doing minimal installations in a number of contexts. Yeah, it's nothing compared to gnome. It is a pretty significant fraction of debian's current minimum footprint. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9ee25b2c-33a6-11e4-a3dc-00163eeb5...@msgid.mathom.us
Re: Checking for services to be restarted on a default Debian installation
On Tue, Sep 02, 2014 at 01:41:05PM -0700, Jameson Graef Rollins wrote: This package is "Priority: optional", and therefore not installed by default. What about just making it "important" or "required"? On my system it pulled in more than 20MB of dependencies. That's a lot to push onto every debian system. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/eec95f46-336a-11e4-9da6-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Thu, Jul 17, 2014 at 12:55:10PM -0400, Hans-Christoph Steiner wrote: Not without modifying the apt config. The point here is to have a working system that is tested and audited, rather than just a set of instructions or recommendations. That would be why you'd create a wrapper to faciliate the config changes necessary for your particular situation. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4bea5e4e-0dd9-11e4-b619-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 16, 2014 at 01:45:36AM +0200, Holger Levsen wrote: AIUI Hans-Christoph wants something else _also_, not instead. And technically I think those signed .debs even exist already, via hashes in signed .changes files. Or am I getting something wrong? Yes you are--what you described is exactly how the Release files work. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2d6a9800-0cd3-11e4-a8ca-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 04:24:38PM -0400, Hans-Christoph Steiner wrote: I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pretty widespread: think Android, Fedora, Java, iOS, etc. I think it is the cleanest approach for the problem that I've outlined. Except that you haven't addressed *at all* why the current mechanism is insufficient, except that you don't like it and want to do something else instead. You understand why that argument isn't particularly compelling. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/934303a6-0c60-11e4-b95c-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: How do you propose managing a distro that mostly needs apt as is, but other times need "Acquire::Check-Valid-Until off;"? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. Um, so does your suggested change. Using apt with the valid check off is fundamentally equivalent to using signed .debs. Both mechanisms have the same failure modes, but one is a configuration change and one reworks the trust path to get to the same place. is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. This is funcationally the same thing as checking that the hash of the deb is the same as the one listed in the Releases file (or apt-cache show) before installing the deb. You could do that in a wrapper. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. Right, as I said, a complete reworking of the trust path (new code, new bugs, etc.) to get essentially the same result. It sounds like what you need to do to get the result you're talking about is grab the releases file along with the deb, validate the sig on the releases file (except ignoring the expiration), verify the hash of the .deb, then install the .deb. Depending on the specifics of the implementation you could do that from an apt command line by setting the Check-Valid-Until via -o or by writing a dpkg wrapper. In any event it shouldn't be all that much code and certainly much less what you're proposing. (I'd also hope that your front end would at least tell the user how old the Release file is, and that the distributor recommends checking for a newer version. The expiration mechanism is important to ensure that people aren't installing old/vulnerable versions of trusted packages--which may be equivalent to installing trojan packages.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6e73f5b0-0c49-11e4-ac7f-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote: Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot of work to create a system which is duplicative at best and less secure at worst. Sure, those options would work well for people who understand them and want to tweak them. I'm not interested in that. I'm currently working on a TAILS-based system for running build and signing processes on machines that _never_ go online. So that means that changing the apt config is not an option. I'm working with apt-offline currently and that helps a lot. You're making an assertion and not supporting it. Changing a configuration parameter is unacceptable, but switching to an entirely different package trust model is ok? You care very much about the trust path to debian packages but not anything else (like the software that's installing them?) Seems like a weird problem, but maybe you're just not fully explaining it. If that's really the constraint set I guess it may be a case of "you created your problem, so you get to fix it". TAILS is a live CD, but provides a method of installing and maintaining new packages on top of what is provided by the live CD. That means those packages are stored in an encrypted stash, and are installed on each boot. So in order to use this feature, the apt cache needs to be refreshed using apt-offline at least every two weeks, otherwise the packages won't be installed since apt can no longer validate them. Have you actually tried setting "Acquire::Check-Valid-Until off;" in apt.conf? What was the result? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d4a2c78e-0b7d-11e4-b7fa-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote: One place that this will help a lot is managing completely offline machines, like machines for running secure build and signing processes. Right now, in order to install a package securely on an offline machine, I have to make sure that the apt-get cache is no older than two weeks, otherwise apt-get considers the info expired and no longer trusted. It make sense to have a listing of packages and updates expire. It does not make sense to have the signature on an individual package expire. Debian does not provide the later option. Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot of work to create a system which is duplicative at best and less secure at worst. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/b0a0301e-0b79-11e4-8363-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 11:56:43PM -0400, Darius Jahandarie wrote: Someone who is unwilling to click past the first link /now/ may become very willing to continue clicking once they read it. "Debian will not protect you against nation-state adversaries" is a very useful bit of information for many non-technical activists, which often leads to the questions: * "Why?" (what powers can they use to subvert existing protections?) * "What /does/ protect you?" (what new protections need I put in place such that those powers cannot subvert them?) It would be lovely to have the answers nearby. Feel free to start writing. I challenge you to point to any OS with a simple, useful, and reliable guide to protect against a determined and well funded adversary. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fee48c46-082e-11e4-8bb2-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 10:24:18PM -0600, Kitty Cat wrote: I seem to remember being offered security updates for the kernel, OpenSSL, SSH, etc. where my only option was to download untrusted packages. I would get warning messages from aptitude about installing security updates. Probably a configuration error. This should be rare with the current defaults, and would be worth a question before proceeding to install untrusted packages. Maybe there should be written a document that describes in detail in easy to understand language what steps to take to verify keys and verify that apt has not been compromised in an already installed system. And also verifying that GPG has not been compromised. You can't. There's a long answer, but the short answer is that it isn't practically possible. of use. Particularly useful would be instructions to check to see if your system has been compromised by validating all already installed packages. MS Windows has an option to check installed Windows components. Which is useless in real-world terms. If it wasn't, we wouldn't see windows botnets. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9571e786-082e-11e4-b7eb-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 11:11:44PM -0400, Darius Jahandarie wrote: If Tux Q. Debiannewbie doesn't know what adversaries with what powers they are/aren't protected against for their use cases without looking hard and being a security expert, it's hard to make serious claims that Debian is actually protecting its users. I frankly find it hard to believe that someone who is unwilling to click past the first link when researching actually cares much about any kind of writeup of threat models. I'll make it simple: if you're completely unsophisticated and worried about a government hijacking your linux distribution to spy on you, there's nothing debian can do to help you. If you're low profile and uninteresting, the government doesn't care about you. If you're actually being targeted by well funded and sophisticated adversaries, they're going to get you unless you put a heck of a lot more effort in than clicking on the first link. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/efdda2b2-07e0-11e4-bd13-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 10:15:59PM -0400, Darius Jahandarie wrote: It would be nice for this information to be somewhere more formal than in mailing list archives. Threat models are becoming increasingly important to convey to end users. The mailing list discussion referenced the sources... -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/44b71312-07dd-11e4-8a0a-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 06:29:09PM -0600, Kitty Cat wrote: For years I have been concerned with MITM attacks on Debian mirrors. We discussed this literally within the past couple of months on this list, at length. Have you read the archives, including the posts about how to establish a trust path to the ISOs? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710021124.ga27...@mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote: And you know, the funny thing is that MSIE took to "warning" people when there was a mix of encrypted and unencrypted data on a page. How long ago? Yeah, I know, it was so they could display that red herring of a lock for "secured pages". You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. This kind of threat analysis is why so many of us are still skeptical of the need for HTTPS package mirrors. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/37d34a1a-057d-11e4-bb7f-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote: Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. Yes, and MS does similar. The difference is, they own their infrastructure and debian relies on donations. It's a lot harder for debian to control the certificates on third party machines than it is for a big company to control the certificates on its own machines. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/44a67e28-02e5-11e4-943d-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. I break it down into 4 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. HTTPS won't address #1 completely in the presence of mirrors, and debian doens't have the resources to serve all users without mirrors. It will not address #2. It may address #3, but less reliably than the current siutation. It may make #4 harder for certain scenarios, but not others (traffic analysis of specific host). Something like tor will be a better solution for #2, & #4 while the current system provides #1 & #3. (And also provides #2 for all practical purposes, given the length of the mirror list.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e4cb4f22-02c8-11e4-904c-00163eeb5...@msgid.mathom.us
Re: [SECURITY] [DSA 2954-1] dovecot security update
On Tue, Jun 10, 2014 at 02:08:48PM +0200, Matus UHLAR - fantomas wrote: I want to say that debian LTS team are volunteers, but they are not "other" than debian security team, because some of them are in both teams. afaik "other" would imply that people from LTS are not in the debian security team, while "rather" would not. "rather" in context implies that the debian security team is paid "rather" than being volunteers. Saying "LTS consists of a different set of volunteers than the debian security team" conveys what you're trying to say, I think. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/78b3872e-f098-11e3-88c0-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 09:43:47PM +0200, Erwan David wrote: Note that at least debian.org DNS is segned by DNSSEC and DANE is used, which allows to check that the certificate used by a debian.org site is the real one. We're not at the point where that can be relied on in the real world. There are still resolvers that filter out DNSSEC records. (Sad, but true.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8bcb9ec8-e84b-11e3-9d19-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:35:58AM -0700, Jeremie Marguerie wrote: In the end, the PPA can do pretty much whatever it wants from your system and this is scary. This is a hard problem to protect against and the only protection I see is... only install PPAs you can trust. Yup; any pinning mechanism you add could be removed by a trusted malicious package. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/240fd966-e828-11e3-9f93-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Sat, May 31, 2014 at 12:46:12AM +1000, Alfie John wrote: Sorry for asking questions. Don't apologize for asking questions, it's perfectly reasonable to do so and you'll find that many people in debian are more than happy to answer questions. Just make sure that you put in enough effort yourself to ensure that you can actually engage constructively when you get an answer. (And if some of the answers point to documentation, make sure that you can't find the answers in the documentation.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/90cece00-e809-11e3-b232-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Sat, May 31, 2014 at 12:32:59AM +1000, Alfie John wrote: I'm definitely wanting to engage in serious discussion. I'm an avid Debian user and am wanting to protect its users. This *is* the Debian security mailing list after all right? All I was trying to do is ask questions as to why it is currently not being HTTPS-enforced and I got flamed for it. Well, you haven't shown any sign of having studied the publically available documentation or checked the public archives relating to the design decisions. Yes it's the debian-security mailing list, but that doesn't mean that it's scalable for debian to provide a personal walkthrough of the entire package signing architecture for everyone who sends an email to the list, does it? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d07185d6-e807-11e3-8a0e-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Sat, May 31, 2014 at 12:11:28AM +1000, Alfie John wrote: On Sat, May 31, 2014, at 12:06 AM, micah anderson wrote: . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... It's only metadata, so who cares right? Only kidding. This is a totally legitimate scenario which I didn't think of. Nice. So your solution to adding privacy is to make sure that every debian system checks in with debian directly rather than using a distributed infrastructure? I'd suggest looking at apt-transport-tor instead. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/68c76176-e807-11e3-91cf-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote: Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be skipped (hence NOP). I'm not sure why you're bringing libc and libgpg into the conversation. You were given a solution which is cryptographically sound and with a verifiable trust path, and you're rejecting it because you simply don't like it and would rather see a different solution with a weaker trust path. I'm not sure why you're continuing this argument. If you want to engage in a serious discussion about enhancing the current implementation or adding additional options, I'd suggest that you first study how the current implementation works, why it was implemented the way it was, the constraints inherent in the distributed mirror model, etc. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530141153.gb29...@mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:25:58PM +1000, Alfie John wrote: Well yes, that's something. But serving Debian over HTTPS would prevent the need for this. No, it wouldn't--you'd just have a different set of problems. Given that mirrors are distributed, it would probably be much more likely that you'd improperly rely on a compromised mirror simply because it's serving files via https. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1db1c630-e7fe-11e3-b616-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote: That's why you verify the initial install media per the link I posted earlier... Oh, and those key fingerprints are on an https page for those who actually trust the CA system. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f2a5e71e-e7fd-11e3-bb9d-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:13:31PM +1000, Alfie John wrote: As what I posted earlier, all you would need to do is to MITM the install of APT during an install. Who cares what the signatures look like since you've NOPed the checksumming code! That's why you verify the initial install media per the link I posted earlier... -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/90ebee24-e7fd-11e3-89ae-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: What's stopping the attacker from serving a compromised apt? https://www.debian.org/CD/verify -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2169b45e-e7f9-11e3-851d-00163eeb5...@msgid.mathom.us
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bfad3c3a-e7f4-11e3-8753-00163eeb5...@msgid.mathom.us
Re: MIT discovered issue with gcc
On Sat, Nov 30, 2013 at 06:30:50PM -0600, Jordon Bedwell wrote: On Nov 30, 2013 6:29 PM, "Bernhard R. Link" wrote: I think the only answer to those lines is to advise you to not use any programs written in C. I suggest writing everything in Haskell and compiling that to java byte code run in a jvm. With the jvm implemented in Haskell and running in an interpreter. That'll be interesting to see. Well, you're in luck--you'll have plenty of time to watch it execute. Mike Stone -- 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/e47f4662-5b53-11e3-bc71-001cc0cda...@msgid.mathom.us
Re: MIT discovered issue with gcc
On Mon, Nov 25, 2013 at 03:10:07PM -0700, Bob Proulx wrote: In those systems the zero page is initially bit-zero and reading from the zero point will return zero values from the contents there. If the program writes to the zero page then subsequent reads will return whatever was written there. This is bad behavior that was the default due to bugs in much legacy software. Unmapping the zero page will cause those programs to segfault and therefore the vendors default to having the page mapped to avoid support calls from their customers. ... This is one of the areas that needs to be addressed when people port software developed on a legacy Unix system over to a GNU/Linux system. If the software wasn't written with this in mind then it might be buggy and will need runtime testing to verify it. To be fair, the software was already buggy, and likely had nearly-impossible-to-diagnose runtime errors caused by null pointer derefs yielding whatever junk was left in memory. Mike Stone -- 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/7f8d5e92-56c6-11e3-a86f-001cc0cda...@msgid.mathom.us
Re: process to include upstream jar sig in Debian-generated jar
On Sun, Sep 01, 2013 at 12:36:59PM +0200, Florian Weimer wrote: How so? The code that performs the signature check (or reports the failure) relies on bits that we (Debian) ship. It's impossible to bootstrap trust, unless you already trust Debian. There's no such thing as perfect security, only a series of tradeoffs. I'm honestly not familiar with the exact circumstances, but I'm assuming that the signature in question is validated via the jvm CA trust path. Is there an alternative way to sign a java applet in a debian autobuilder with a trusted key? You can obviously argue whether that's a useful property, but if you're a user who wants to be able to follow a consistent process between the debian version and other versions it's certainly nicer for it to "just work" rather than getting an explanation of why the debian way is better and what the user is trying to do doesn't make sense. Mike Stone signature.asc Description: Digital signature
Re: process to include upstream jar sig in Debian-generated jar
On Thu, Aug 29, 2013 at 11:35:47AM +0200, Sébastien Le Ray wrote: Yes but the whole thing looks weird, on one hand OP wants to include a signed jar in the package, on the other hand he says "signature could be omitted if quick update is needed"… What's the point having signed JAR if unsigned JAR is legitimate too? Either you ban unsigned JARs or you don't use signed JAR at all… It leaves that decision of whether to run with the unsigned jar up to the user. I think this is a reasonable solution if it works in practice, and is similar in concept to what the openssl folks have done for FIPS validation. Mike Stone signature.asc Description: Digital signature
Re: Compromising Debian Repositories
On Wed, Aug 07, 2013 at 05:26:24PM +0100, Daniel Sousa wrote: I think most of you are foccusing in servers running Debian, but when I asked the question I was thinking about personal computers. For example, if there are any vulnerabilities on ssh, they won't be able to get into my computer anyway because I'm always behind a NAT (and I'm not even sure that I have ssh on this computer). That's why most attacks these days are launched against client systems rather than servers. Do you use a web browser on the internet? If yes, then somone can target you with an exploit. Mike Stone -- 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/70b5086c-ff81-11e2-b16f-001cc0cda...@msgid.mathom.us
Re: Compromising Debian Repositories
On Mon, Aug 05, 2013 at 09:11:21PM +0100, Joe wrote: I don't think there is a goal, I think we are all ruefully conceding that the much-vaunted Open Source process is simply unable to deliver trustworthy code, since the process of compiling the Open Sources to binary involves using utterly un-auditable binaries, running on un-auditable processors manufactured by a very small number of companies. We can also assume that if something is technically possible, perhaps involving the outright purchase or intimidation of a few hundred humans, then the largest organised crime syndicates on the planet (a.k.a. governments) will do it. Anything humans can make, humans can un-make. Welcome to reality. Is this something you need to lose a lot of sleep over? No, probably not. There's what is possible, and then there is what is likely, and we probably have more practical issues to spend time on. Mike Stone -- 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/490c356c-fe85-11e2-a8fa-001cc0cda...@msgid.mathom.us
Re: Compromising Debian Repositories
On Sun, Aug 04, 2013 at 05:13:51PM +0100, Daniel Sousa wrote: First of all, they could apply that change (calling it a patch was not one of my greatest ideas) for every update they do, it's not necesserily a one time thing. It's also much easier (and probably much dangerous) to write some code that doesn't need to be cryptic, you can just write whatever you want instead of trying to find something that can pass as a mistake (although this seams a fun thing to do) If we're being all cloak-and-dagger and reveling in the possibility of the NSA infiltrating the archive, why wouldn't you assume 1) the desire for plausible deniability and 2) competence? A simple exploitable bug in a sensitive service gets you root access, why do you need something more fancy? History has shown that remote root vulnerabilities can survive in for quite a while in some pretty old code. I don't think we need to focus on someone trying to insert individual malicious binaries into the archive until that actually becomes the more straightforward and less risky attack vector. Mike Stone -- 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/e4e22be8-fd47-11e2-bac1-001cc0cda...@msgid.mathom.us
Re: Compromising Debian Repositories
On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote: I think the real issue is about if the malicious patch is not part of the source package Why? It certainly makes your argument simpler if you arbitrarily restrict the problem set, but it isn't obvious that it makes sense. If I was going to backdoor something, I'd just make an innocent-looking coding error that would enable a successful exploit; I certainly wouldn't put in a commented section of code that says "backdoor here". With sufficient effort it wouldn't be hard to inject such a vulnerability that would go unnoticed for years--and I'm not sure why that's less of an issue than someone making a one-time build with a malicious patch that is not part of the source package. Mike Stone -- 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/b31dba54-fd0c-11e2-a173-001cc0cda...@msgid.mathom.us
Re: [volatile] Updated clamav-related packages available for testing
On Thu, Apr 15, 2010 at 02:29:58PM -0600, Jason Kolpin wrote: seem to simply refuse to work with. I fail to understand this, and I'm no genius but there must be a way for the entire Debian team to figure some sort of elegant, permanent, and secure solution to this whole thing instead of patching it with bubble gum and bailing wire every time this link in the chain breaks. I mean really, the developers must realize that some things in this technical world change too fast for inclusion in the standard repositories yet these packages are something no publicly facing machine should do without. deb http://volatile.debian.net/debian-volatile lenny/volatile main -- 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/1d084ac0-48d3-11df-9b6a-001cc0cda...@msgid.mathom.us
Re: ipv6 and security.debian.org
On Wed, Jan 13, 2010 at 06:18:02PM -0600, Boyd Stephen Smith Jr. wrote: IPv6 uses path MTU detection. So does IPv4 these days, doesn't mean people don't break it. :-) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ipv6 and security.debian.org
On Wed, Jan 13, 2010 at 08:59:18PM +0100, Martin Zobel-Helas wrote: Can you give us a tcptraceroute6 to from your machine to security.d.o? Also, can you download from other servers with ipv6? Could be local mtu issue if nothing works. (Ping would be ok, but large TCP downloads would flake out.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ipv6 and security.debian.org
On Wed, Jan 13, 2010 at 05:37:20PM +0100, Eelco Jepkema wrote: ;; ANSWER SECTION: security.debian.org.263 IN 2001:a78::16 security.debian.org.263 IN 2001:8d8:2:1:6564:a62:0:2 security.debian.org.263 IN 2001:a78::1a This seems to work then. Now however I do "apt-get update" but it hangs on security.debian.org. Am i doing something wrong or is security.debian.org doing something wrong (i.e. not making the mirrors available on http ipv6)? In general, ipv6 security updates work fine (I've been using them for a while). Note that the server you get is determined by where you are: ;; ANSWER SECTION: security.debian.org.32 IN 2001:4f8:8:36::6 so there might by a problem with your particular mirror; you might try contacting mirr...@debian.org. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: instantbird: modified libpurple
On Wed, Nov 25, 2009 at 01:28:41AM +0100, Bernd Eckenfels wrote: In article <0e753136-d929-11de-9b6a-001cc0cda...@msgid.mathom.us> you wrote: My inclination is to say that this sort of thing is largely unsupportable in a debian release. It's fine for unstable, but 2-3 years from now is anyone going to be writing patches for instantbird 0.1.3.1 and its forked version of libpurple? Hu? This is an open source project with a forked code base like any other project? Why dont you simply treat it as such? Because of the history of what happens with projects that get put into stable when they are version 0.1.3.1 as well as the history of what happens with complex network client applications in general. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: instantbird: modified libpurple
On Tue, Nov 24, 2009 at 07:18:29PM +0100, Gabriele Giacone wrote: it is not possible to build instantbird with system libpurple. I forward you the instantbird developer explanation and Mike Hommey point of view. What do you think about? Can a package like this be accepted? If you want to take a look at my package, [2] My inclination is to say that this sort of thing is largely unsupportable in a debian release. It's fine for unstable, but 2-3 years from now is anyone going to be writing patches for instantbird 0.1.3.1 and its forked version of libpurple? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Wed, Jul 08, 2009 at 11:18:43PM +0200, Sebastian Posner wrote: Jim Popovitch wrote: Is there a way to force keys AND passwd verification? Normally you'd want to DISABLE PasswordAuthentication and ChallengeResponseAuthentication ... Something that would indeed be interesting is a way to enforce that the PRIVATE KEY is password-protected - sadly, you can't see this from the public key, and I'm not aware of any possibility to query the client concerning this specific matter. You can't, which is why it is useful to have both passwords and keys simultaneously--you can enforce a policy on a password. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fwd: On Wireshark and network capture in general
On Fri, Jun 19, 2009 at 01:56:05PM +0200, Josselin Mouette wrote: Le vendredi 19 juin 2009 à 12:54 +0200, Jaap Keuter a écrit : > What I've noticed is that Debian (still) requires the user to run > Wireshark with root credentials in order to be able to launch a > network > capture. Otherwise the network interfaces won't even be visible. > This problem, running a massive GUI application with root > credentials, was > identified long ago and addressed as such. The core capture > functionality > was isolated in a capture child, so the rest (dissection, GUI, etc) > could > be run as a normal user. This only(ahem) requires the capture engine > (dumpcap) to be installed setuid root. I think it’s just as bad an idea to launch dumpcap setuid root as it is to launch the GUI as root. Definitely as default for the install. For many people the common case is to use wireshark to analyze captures taken by a different tool, and there's no reason for them to automatically have anything setuid to support that case. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Mon, Jun 01, 2009 at 12:31:04PM +0100, Marcin Owsiany wrote: Note that this seems to be a simple "expect(1)" script which runs a shell. Not necessarily an indication of anything apart from a possible attacker trying to exploit something using expect. It's also an indication that the attacker could write to the filesystem... Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Mon, Jun 01, 2009 at 10:46:54AM +0200, Johann Spies wrote: I am a bit worried that my computer have been compromised. ... I think the last three lines are not problematic but in /dev/shm/r I found: spawn /bin/bash interact Do I have reason to be worried? Yes, that's a typical location for intruders to drop files. Easiest thing to do is reinstall after thinking about how the compromise may have occurred. (Did you update regularly, including kernel updates? Did all accounts have strong passwords? Do you have web applications not managed by the system that weren't being updated? etc.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-team] Security support for volatile?
On Mon, Feb 23, 2009 at 07:27:14PM +0100, Kurt Roeckx wrote: I think one the reason why clamav is in volatile is that the engine might need updating to detect new viruses. Is that something you want to support in stable-security? I think there's a couple of questions to answer: 1) is there any point in deploying a virus scanner with outdated definitions? 2) is volatile well known enough that everyone installing a virus scanner with debian is using the version in volatile? Mike Stone -- 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, Dec 31, 2008 at 02:15:18PM -0500, Micah Anderson wrote: Does anyone have a legitimate reason to trust any particular Certificate Authority? Of course--some charge *lots* of money, and we all know that expensive bits are better than cheap bits. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#311772: Fwd: Password leaks are security holes
On Thu, Aug 28, 2008 at 02:37:37PM -0700, Steve Langasek wrote: On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, Then there is a bug in another package if this is what "should" be, because /var/log/auth.log is readable by group adm on all my systems. By default, nobody is in adm. Once upon a time (and still, on some systems) people made syslog world readable so people could diagnose their own problems. auth.log lets you keep syslog world readable without disclosing potentially sensitive authentication information. (It's true that the passwords are not in /etc/shadow for systems using pam_unix together with NIS or NIS+, but I consider both NIS and NIS+ rather uninteresting cases.) I'd say they're interesting, but increasingly uncommon. I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. It provides information about username brute force attacks and other issues of concern to admins. Note that the pam_unix behavior is a bug, because it only logs some names of non-users; presumably it should log all or none. Whether this is a security bug is debatable (I think not). Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misunderstanding about normal (stable) and security channels
On Mon, Jul 28, 2008 at 03:20:56PM +0200, Frédéric PICA wrote: In the tool I'm developping, I rely on the package channel to know if a package was installed because of a security concern or not (never mind if this is a minor one or not) and now I can't be sure of the update type. Is there a more or less simple way to know a package type (security, bugfix, ...) ? You're overestimating the degree of difference between a "security" fix and "just a bugfix". In other words, you're never going to get what you want because there will always be bugs where people argue about whether it warrants a security label--reference a recent discussion on linux-kernel about this very issue. Time would better be spent testing stable updates for installation rather than trying to classify them; at some point it doesn't really matter whether your machine crashed due to an obscure bug labeled "DOS" or an obscure bug labeled "hard to reproduce CRASH". Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass-updating cached hosts keys afrer ssh security upgrade?
On Mon, Jul 21, 2008 at 06:43:31PM -0500, JW wrote: This has turned into an unexpected nightmare: my users have, between them all, dozens of cached host keys, and they are nearly unable to work because every time they turn around they're getting bad-old-cached-key warnings (REMOTE HOST IDENTIFICATION HAS CHANGED). I'd suggest investigating using ssh-keyscan to generate a common /etc/ssh/ssh_known_hosts file for all your machines, rather than trying to manage it on a per-user basis. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Study: Attacks on package managers (inclusing apt)
On Fri, Jul 18, 2008 at 09:56:45PM +0200, Goswin von Brederlow wrote: See the latest DNS vulnerability about how you can compromise a clients DNS without having to hack a DNS server. Thanks, I had heard of it. Note that you ignored the part about keeping it compromised. For this attack to be successful you need to keep the DNS wrong forever--you can't ever let an update slip through. That's a very different scenario then "hijack one session and you win". Only way people notice a spoofed dns reply is when they saw a security update being announced and apt-get won't get it. Not everybody does, some people just run apt get and trust it to work. Well, these things are announced for a reason. We can't protect people from themselves, and it's a long standing principle of debian security updates that running apt-get in a cron job is not a complete replacement for reading the advisories, for far more reasons than this single issue. Bottom line: it's a network update across the internet--there will be ways to DOS the update. The best mitigation is to use diverse mechanisms to validate that your system has the updates you expect it to have. We've implemented that mitigation. Other proposed mitigations have their own issues (e.g., the "autosign the release in a cron job", which makes it *much* easier to sneak bad things in) or just move the goal posts a little bit (e.g., using https, which leads to questions about how we would validate the certs and simply changes what people would have to do to facilitate exactly the same attack ["we could use a CRL if the cert was compromised" "but what if I use a DNS trick to block the CRL check indefinitely?"].) Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Study: Attacks on package managers (inclusing apt)
On Fri, Jul 18, 2008 at 01:17:43PM +0200, Goswin von Brederlow wrote: Or just one DNS server or even just the users client. You'd also have to keep the DNS server wrong. Doing this in a manner that people don't notice is (IMO) hard, because people do go looking for particular security updates. And if the client is already compromised, who cares about whether the update mechanism has theoretical issues? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Study: Attacks on package managers (inclusing apt)
On Thu, Jul 17, 2008 at 03:54:02PM -0400, Jim Popovitch wrote: But as long as Release.gpg/Timestamp.gpg are local to the mirror(s), and not only on a master, the various .gpg files and packages can, even though difficult, be modified on the single mirror. IMHO, verification needs to have an alternate channel than the downloads. If someone can modify gpg signatures we have a bigger problem that can't be solved by any solution proposed thus far. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Study: Attacks on package managers (inclusing apt)
On Thu, Jul 17, 2008 at 11:30:12AM -0400, Micah Anderson wrote: Although PGP-signed Release file prevent tampering with files, the attack doesn't require tampering with files or tampering with signed release files. If I were to MitM security.debian.org, I could provide an outdated (yet properly signed) mirror of the security packages to you. I would simply supply, via a MitM, a mirror that was not updated, so that the packages you were getting were valid and signed. They just are out-dated, so that you would not receive critical security upgrades. Sure. Luckily we have multiple channels by which information about security updates is distributed, so people will know if they are missing updates. Note that you will have to MITM multiple servers as security.debian.org is a round robin, and any update of the Packages will invalidate older versions. Following on that attack is the fact that its easy to join the mirror network and once you are in, you can do the same thing as above and keep your mirror a day or four out of date, so that people who use your mirror aren't getting updates for issues that enter through the normal channels. You also have a list of IPs that use your mirror that don't have these updates. It is not easy to become a security mirror. Becoming a non-security mirror doesn't lead to obviously interesting attack. Unless you're talking about people tracking unstable, but in my experience people tracking unstable notice if a day passes without updates... Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Study: Attacks on package managers (inclusing apt)
On Thu, Jul 17, 2008 at 04:46:54PM +0200, Daniel Leidert wrote: Today there were some news about a study from the University of Arizona regarding security issues with package management systems (like apt). I did not yet read the whole study, but probably it's interesting for the project (they write about "vulnerabilities"). The study is here: It doesn't appear that they had a firm grasp of how package distribution actually works in debian, at least. Mostly it seems like oversensationalized attention-grabbing. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dowkd.pl false positives
On Fri, May 23, 2008 at 04:31:15PM +0200, you wrote: * Dirk-Willem van Gulik: Could be. Anyway, I'm ready disprove any false positive claims by providing key material. So far, that's been quite successful. Do you have below key on your list ? Yes, I have. It's being worked on. Does that mean "yes it is a false positive", "no it's not a false positive", or "it's not yet clear whether or not it's a false positive"? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: openssh remote upgrade procedure?
I'd suggest posting your sshd_config & your ssh -v output. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel upgrade for 3Ware Driver issues?
On Wed, Apr 23, 2008 at 09:14:28AM +0200, Vladislav Kurz wrote:
This bight be a little off-topic, but I'd like to know if there is a
definition of what is a "security issue" ? Once I learned that security
consists of confidentiality, integrity and availability. And data corruption
destroys integrity and availability.
CIA is a common way to talk abou the goals of computer security, but it
needs to be scoped. There is no benefit whatsoever to defining
*anything bad that happens* as a computer security issue. ("Oops, I
acidentally deleted my own file"--no, you screwed up, "Oops, the
building burned down"--bigger problem than computer security; "Oops,
aliens destroyed the planet"--ditto; "oops, flakey driver ate my hard
disk"--systems maintainence issue.) The end result of data security
processes should lead you to backups or some other contingency plan, no
shoving arbitrary software into stable because it scratches your itch.
Instead of blowing the computer security horn because that horn happens
to have resources attached to it, you should pursue the general systems
maintenance horn because that's what this problem is. (The you here is
plural, and this is an industry-wide problem.)
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is oldstable security support duration something to be proud of?
On Sun, Mar 16, 2008 at 03:30:46AM -0400, Filipus Klutiero wrote: The most popular derivative, CentOS, does provide security support. You realize that this consists essentially of recompiling the relevant RHEL update, right? Note that the CentOS advisory even references the parent RHEL advisory... (This means that there is no advisory to write, no patch to be written, no classification to be done, etc.) This isn't to say that the CentOS security team doesn't provide a valuable service, but they are definitely getting a huge leg up from the paid work done for RHEL. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Encrypting drive
On Mon, Jul 09, 2007 at 04:24:30PM +1000, Russell Coker wrote: On Monday 02 July 2007 11:35, Anders Breindahl <[EMAIL PROTECTED]> wrote: In servers, you might want to trust physical security, since whole-system encryption incurs a performance degradation. (However, on a reasonably recent system, you still will be bottlenecked by Fast Ethernet at 100Mb/s). Where "reasonably fast" means faster than a 3GHz P4. A 3GHz P4 system I was working on recently appeared to be limited to 4MB/s, if it wasn't for the fact that the machine is about to be decommissioned then I would probably investigate this further as the performance is lower than expected. There was definately a local problem of some sort; I get well upward of 20MB/s (double fast ether speed) on a 1.6GHz K6, which should be significantly slower than a 3GHz P4. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Thu, Jun 14, 2007 at 11:37:33AM +0200, Steffen Schulz wrote: On 070614 at 00:00, Michael Stone wrote: On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote: >http://www.cits.rub.de/MD5Collisions/ >One example how to create two files with same hash that act >differently. Should work with most active content. Cool. So the security team can rig an executable that can be modified and still have the same md5. Point was: md5 collisions are a real-world problem. If they are, you've failed to show it. >With the above results, it would be possible to officially distribute >nice behaving software but present specific targets with modified >packages that do evil. Yup. Or the security team could just plant a regular backdoor, [..] The critical bit was included in the sentence you removed: What hashes does apt-secure use? Judging from this documentation, md5 is used for apt-secure, too: http://people.debian.org/~walters/monk.debian.net/apt-secure/x35.html So every maintainer could distribute nice binaries and then inject malicious packets to certain targets. Every maintainer can do that without dicking around with md5 collisions. If you don't trust the security team, you probably shouldn't install security updates. Sorry for being unclear, If you don't trust the debian maintainers, you probably shouldn't install debian. Sorry for being unclear. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote: On 070613 at 10:43, Florian Weimer wrote: > AND the fact that it needs to be a valid .deb archive, they are > probably more than strong enough. This is actually not much of a problem: http://www.cits.rub.de/MD5Collisions/ One example how to create two files with same hash that act differently. Should work with most active content. Cool. So the security team can rig an executable that can be modified and still have the same md5. With the above results, it would be possible to officially distribute nice behaving software but present specific targets with modified packages that do evil. Yup. Or the security team could just plant a regular backdoor, and not worry about the md5 hash. A sha hash isn't going to change that at all. If you don't trust the security team, you probably shouldn't install security updates. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Allow password auth for one user with sftp?
On Mon, Jan 22, 2007 at 08:49:08PM +0100, Adrian von Bidder wrote: I trust the users who have shell access to keep their keys secure. I don't trust the users to have unguessable (think dictionary attacks!) passwords. I see dictionary attacks on ssh on a daily basis. Hmm. Which of these two things are controllable on the server side? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When are security updates effective?
On Sat, Sep 02, 2006 at 12:28:17AM +0300, Mikko Rapeli wrote: - can a process running vulnerable code be exploited to not show the shared libraries and other non-shared libraries and files it had opened for reading at some point? Of course it can. And that's irrelevant to the question at hand--installing a security update at that point isn't going to help. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1111-1] New Linux kernel 2.6.8 packages fix privilege escalation
On Mon, Jul 17, 2006 at 03:45:25PM +0200, Arnd Hannemann wrote: shouldn't that read CVE-2006-3626 instead? Yes. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
On Tue, May 23, 2006 at 02:10:19PM +0200, marco.celeri wrote: yes, i think this allow incoming spoofed traffic to eth0 (or it is "martian?") but the response must follow what found in routing table -> lo interfaces... am i wong? Yes, but that doesn't necessarily help in the case of a single-packet exploit, for example. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
On Tue, May 23, 2006 at 04:20:58PM +0200, Uwe Hermann wrote: On Tue, May 23, 2006 at 09:53:05AM +0200, LeVA wrote: But if one can spoof 127.0.0.1, then one can spoof anything else, so creating any rule with an ip address matching is useless. Correct. IP-based authentication is inherently flawed. If you want something like that, use strong cryptography to verify the sender/receiver (think certificates, SSL, etc.). No, it's not inherently flawed for loopback addresses on the loopback interface. There are valid reasons to want a different set of rules on the local host than on the network. (E.g., want to be able to test without the complexity of an encryption layer, don't want overhead of encrypting both sides of a local connection, etc.) Aside from that, yeah, ip addresses shouldn't be used for authentication on untrusted networks. (Though they are useful as one layer of security, to mitigate the risk of vulnerabilities in the encryption routines.) Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
On Tue, May 23, 2006 at 10:06:45AM +0200, Rolf Kutz wrote: The script under scrutiny was intended for a laptop. A router or firewall setup is something different and should not route traffic with spoofed addresses. rp_filter should catch this easily, if you can use it. If not, an IP-based rule is ok, IMHO. No, if you mean to accept loopback traffic then you should accept -i lo. If nothing else, all of 127.0.0.0/8 is loopback addresses, not just 127.0.0.1, and I have seen software that makes use of that. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: password minimum days problem
On Thu, May 18, 2006 at 02:39:25PM -0700, [EMAIL PROTECTED] wrote: So how to have PASS_MIN_DAYS set but to allow/require the new user to change his password on the first login? Use passwd -e to force the user to change his password. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: masking out invalid root logins with logcheck?
On Mon, May 08, 2006 at 09:06:37PM +0200, Emanuele Rocca wrote: The only situation I've been able to imagine is a human error leading to a change to your security policy. For instance, a co-worker which temporary allows remote root logins, god knows why. I'd be sad of my choice of filtering out root login attempts in that case. If this configuration error happened and root logins were suddenly allowed, it would be less effective to focus on a reduction in failed root logins than on the sudden presence of successful root logins. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: masking out invalid root logins with logcheck?
On Sun, May 07, 2006 at 09:11:53AM +0200, martin f krafft wrote: machines. On all these machines, sshd root login is restricted to password-less login (RSA/DSA keys), so brute force attacks are never going to succeed. Probably what you want to highlight, then, is a *successful* login. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
