Jose Luis Rivas: > On 09/12/2013 08:32 PM, adrelanos wrote: >> So we have the (intel/amd)-microcode and the firmware-linux-nonfree >> package which should be installed to improve security? Are there any >> other packages of this type? > > Who said they improve security?
Quote: Jonathan Perry-Houts (This thread.) > so yes, installing the firmware-linux-nonfree package is probably wise. And no one challenged this statement. Possibly I misunderstood him, but since this thread is a question with security context on the security mailing list I came to that conclusion. AND Quote: ANNOUNCEMENT: Intel processor microcode security update (On this list, few days ago.) > 1. It fixes a critical erratum, classified by Intel as a security issue, > that affects any server running 32-bit VMs in PAE mode. > > Erratum AAK167/BT248: "If a logical processor has EPT (Extended Page > Tables) enabled, is using 32-bit PAE paging, and accesses the > virtual-APIC page then a complex sequence of internal processor > micro-architectural events may cause an incorrect address translation or > machine check on either logical processor. This erratum may result in > unexpected faults, an uncorrectable TLB error logged in > IA32_MCI_STATUS.MCACOD bits [15:0], a guest or hypervisor crash, or > other unpredictable system behavior" Sounds like this could be potentially used as remote exploit, Intel doesn't really know itself or doesn't want to say. > We don't know what they are. And I doubt > they will patch a backdoor at this moment, [Not sure we use the terms in the same way. When I refer to vulnerability, I mean a mistake which can lead to unauthorized code execution. When I refer to a backdoor, I refer to something which has been deliberately planted to get unauthorized access. Of course, a backdoor could be implemented by looking like a mistake (vulnerability). - Therefore I think patching a backdoor is less likely than patching a vulnerability - because the backdoor should stay?] I meant, patching a vulnerability. [speculation]But well, maybe someone has put a backdoor in before, and now they've spotted it and patched it or have to patch it because they suspect someone has found it or will find it soon.[/speculation] > specially when you don't know > what the hell they have in your hardware. > So my guess is that it's more > likely their microcode is inserting a backdoor instead of patching it. Maybe. Although, I'd speculate, that this is unlikely. What about the likelihood, that it came with a backdoor in the first place? Or maybe they backdoor could not be exploited in all cases and now they are improving it? =) >> >> What would you do if there was an exploit in the wild, which uses an >> vulnerability in (intel/amd)? Let's say any website could prepare some >> html code which would trigger a remote code execution. One that can only >> be fixed by having the (intel/amd)-microcode package installed. > > I doubt there's HTML code with the ability to trigger remote code > execution. More likely some JavaScript which is still hard at CPU level > or an iframe downloading things. This will depend on vulnerability from > all levels to go into the CPU, which is a hard combination to get in the > open-source world. But let's say it's available an exploit like that: we > are an universal operating system because we do not only support > x86/x86_64. My suggestion would be: change your arch. > > I already own several ARM-machines, I suggest you buy something like > this just in case. Interesting. >> >> Is this a possible scenario? > > Everything is possible. >> >> What would you (Debian) do in this case? > > I don't know. We are a community, and I'm not a spokeperson for Debian > although I'm a Debian Developer. I can't answer this. You stated your opinion, all I was asking for. I know, I shouldn't expect a community consensus from such a theoretical question. Was just was interested in some individual opinions. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
