Re: Firewire vulnerability applicable on FreeBSD?



Hi Jeremie,

On 3/22/08, Jeremie Le Hen <jeremie@xxxxxxxxxx> wrote:
Hi there,

I've stumbled on this article. I wonder if this is applicable to
FreeBSD. Would it still be possible to exploit it without a firewire
driver?

http://www.dailytech.com/Lock+Your+Workstations+Or+Not+New+Tool+Bypasses+Windows+Logon/article10972.htm


``That's not a bug, it's a feature''.

That is, the firewire spec requires that it has full read/write access to all
physical memory, in the same way that the PCI bus has full read/write
access to physical memory.

Thus, with direct access to a firewire port, a malicious person can
grub around kernel memory and frob whatever they want (yet
another reason why physical security is important).

It seems that the windows vulnerability was due to storing credentials
information in a consistent place from system to system; that is
certainly the case for a GENERIC kernel, but if you have a custom
kernel there is no longer a _trivial_ ``exploit'' -- an attacker must
do some work to find where things are (and be able to hot-patch
machine language, but I know several people that could do that,
even one that's basing his thesis project on it).

Basically, once an attacker has physical access to your machine,
you've lost; this is just one possible route that such an attacker
could take.

We can use this feature as a true feature, as well, though -- it
allows dcons to be used instead of a serial port for kernel
debugging when you've totally confused your kernel.

-Ben Kaduk
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Google Summer of Code 2009: Student application
    ... at the Linux Foundation we got the application shown below. ... This project sets the goal of partly moving into the kernel (as a FireWire driver with an ALSA interface) what FFADO currently implements in userspace. ...
    (Linux-Kernel)
  • Re: Virtual memory - user space kernel space
    ... In the old days, all physical memory was mapped 1:1 to virtual addresses 0xc0000000 upwards, so the kernel could access everything directly. ... If you had more than 1GB of physical memory, you could recompile the kernel to start at 0x80000000 or even 0x40000000, to accomodate up to 2 or 3 GB of physical memory. ... Linux uses swap space in addition to physical memory, so having 1GB of physical memory and 2GB of swap space would allow you to use 3GB of virtual memory, distributed amongst the kernel and user processes. ... one for kernel and one for the currently active user process, the kernel's low 786432 entries are identical to the user process' low 786432 entries. ...
    (comp.os.linux.development.system)
  • [PATCH 7 of 8] x86: page.h: move things back to their own files
    ... Change your config file and compile the kernel ... * If you want more physical memory than this then see the CONFIG_HIGHMEM4G ... -static inline void clear_page ...
    (Linux-Kernel)
  • Re: BUG: unable to handle kernel paging request at ffff8800cf669000
    ... physical memory are not accessible to the kernel. ... static unsigned long pfn = 0; ... /* This function is called at the beginning of a sequence. ...
    (Linux-Kernel)
  • Re: amd64: change VM_KMEM_SIZE_SCALE to 1?
    ... more than e.g. 1/3 of physical memory means needing more PTEs. ... takes about 4MB reserved as PTE pages to map 2GB of kernel virtual ... But I guess 4MB pages are no good for sparse mappings. ...
    (freebsd-arch)