Re: How secure is an installation with with no non-free packages?
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.
Reply to: