/dev/ksyms permissions
This leaks information that unprivileged user probably has no reason to own: > cat /dev/ksyms > ksyms > readelf -a ksyms |wc -l 47594 Any strong reason not to apply the following? Presumably it will have benefits for GENERIC_KASLR, or people with Intel CPUs :-) Index: MAKEDEV.tmpl === RCS file: /cvsroot/src/etc/MAKEDEV.tmpl,v retrieving revision 1.189 diff -u -r1.189 MAKEDEV.tmpl --- MAKEDEV.tmpl9 Jan 2018 03:31:14 - 1.189 +++ MAKEDEV.tmpl17 Jan 2018 15:19:04 - @@ -933,7 +933,7 @@ mkdev fullc %mem_chr% 11 666 mkdev zeroc %mem_chr% 12 666 mkdev klogc %log_chr% 0 600 - mkdev ksyms c %ksyms_chr% 0 444 + mkdev ksyms c %ksyms_chr% 0 400 mkdev random c %rnd_chr% 0 444 mkdev urandom c %rnd_chr% 1 644 if ! $fdesc_mounted; then
Re: /dev/ksyms permissions
libkvm uses it to get the kernel symbol namelist instead of reading /netbsd for it (originally kvmdb, which was retired when ksyms was added). Programs like ps, netstat etc... uses it to find in-kernel stuff, so you cannot change it to require root privs to be read. Maybe group kmem read, but that might require more elevated privileges in the programs that uses ksyms. -- Ragge Den 2018-01-17 kl. 16:25, skrev co...@sdf.org: This leaks information that unprivileged user probably has no reason to own: cat /dev/ksyms > ksyms readelf -a ksyms |wc -l 47594 Any strong reason not to apply the following? Presumably it will have benefits for GENERIC_KASLR, or people with Intel CPUs :-)
Re: /dev/ksyms permissions
In article <20180117152524.ga11...@sdf.org>, wrote: >-=-=-=-=-=- > >This leaks information that unprivileged user probably has no reason to >own: > >> cat /dev/ksyms > ksyms >> readelf -a ksyms |wc -l > 47594 > >Any strong reason not to apply the following? >Presumably it will have benefits for GENERIC_KASLR, or people with >Intel CPUs :-) > >-=-=-=-=-=- > >Index: MAKEDEV.tmpl >=== >RCS file: /cvsroot/src/etc/MAKEDEV.tmpl,v >retrieving revision 1.189 >diff -u -r1.189 MAKEDEV.tmpl >--- MAKEDEV.tmpl 9 Jan 2018 03:31:14 - 1.189 >+++ MAKEDEV.tmpl 17 Jan 2018 15:19:04 - >@@ -933,7 +933,7 @@ > mkdev fullc %mem_chr% 11 666 > mkdev zeroc %mem_chr% 12 666 > mkdev klogc %log_chr% 0 600 >- mkdev ksyms c %ksyms_chr% 0 444 >+ mkdev ksyms c %ksyms_chr% 0 400 > mkdev random c %rnd_chr% 0 444 > mkdev urandom c %rnd_chr% 1 644 > if ! $fdesc_mounted; then Perhaps 440 $g_kmem, if you don't want to break the world :-) christos
Re: /dev/ksyms permissions
> libkvm uses it to get the kernel symbol namelist instead of reading > /netbsd for it (originally kvmdb, which was retired when ksyms was > added). Programs like ps, netstat etc... uses it to find in-kernel > stuff, so you cannot change it to require root privs to be read. But the symbol values are useless except for reading kernel memory (and kernel-side debugging, which latter I think we can assume can assume root access for). So I see no harm changing /dev/ksyms to be 440 root:kmem. (I don't _like_ it, and would configure my own systems otherwise, but that's for much the same reasons I dislike kaslr, which are fairly specific to my use aptterns.) > Maybe group kmem read, but that might require more elevated > privileges in the programs that uses ksyms. What program uses ksyms now that doesn't require at least group kmem? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: /dev/ksyms permissions
Den 2018-01-17 kl. 20:03, skrev Mouse: Maybe group kmem read, but that might require more elevated privileges in the programs that uses ksyms. What program uses ksyms now that doesn't require at least group kmem? You cannot give up kmem read privileges when calling ksyms read routines. Think setegid(). -- Ragge
Re: /dev/ksyms permissions
>>> Maybe group kmem read, but that might require more elevated >>> privileges in the programs that uses ksyms. >> What program uses ksyms now that doesn't require at least group kmem? > You cannot give up kmem read privileges when calling ksyms read > routines. I don't see why not - or, at least, I don't see the ksyms change as being relevant. Just read /dev/ksyms at startup (at the same time as you open /dev/kmem, probably), before dropping group kmem. Isn't that all this change (making /dev/ksyms 440 root:kmem) requires? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: /dev/ksyms permissions
Den 2018-01-17 kl. 20:20, skrev Mouse: Maybe group kmem read, but that might require more elevated privileges in the programs that uses ksyms. What program uses ksyms now that doesn't require at least group kmem? You cannot give up kmem read privileges when calling ksyms read routines. I don't see why not - or, at least, I don't see the ksyms change as being relevant. Just read /dev/ksyms at startup (at the same time as you open /dev/kmem, probably), before dropping group kmem. Isn't that all this change (making /dev/ksyms 440 root:kmem) requires? You still have to call library functions with elevated privileges compared with today. May not be a big problem, but the code should be audited first and this behaviour documented. -- Ragge
Re: amd64: kernel aslr support
On Wed, Jan 17, 2018 at 08:01:19AM +0100, Maxime Villard wrote: > Or, you can dump the location of the segments by loading a kernel module > that calls the following function ... > It will give you the addresses of the pages containing the kernel sections. > Note however that the sections may not start exactly at the printed addresses, > they are shifted. Thanks, that worked. I've attached the kernel module I wrote (put it in src/sys/modules/aslr_test). Here's the output: GENERIC: Segment 0 (text): va=0x8020 size=12582912 Segment 1 (rodata): va=0x80e0 size=6291456 Segment 2 (data): va=0x8140 size=8388608 KASLR, boot 1 Segment 0 (text): va=0xc340 size=2097152 Segment 1 (rodata): va=0xfa0ec000 size=4096 Segment 2 (rodata): va=0xf5e0 size=2097152 Segment 3 (rodata): va=0xbd80 size=2097152 Segment 4 (rodata): va=0x9fb39000 size=4096 Segment 5 (rodata): va=0xa12a6000 size=4096 Segment 6 (rodata): va=0xd7872000 size=4096 Segment 7 (rodata): va=0xe37e2000 size=4096 Segment 8 (rodata): va=0xa4f15000 size=4096 Segment 9 (rodata): va=0xcb613000 size=4096 Segment 10 (rodata): va=0xbf82a000 size=4096 Segment 11 (rodata): va=0x95414000 size=4096 Segment 12 (rodata): va=0xbf8f1000 size=4096 Segment 13 (rodata): va=0xa0fa2000 size=4096 Segment 14 (rodata): va=0x835b5000 size=4096 Segment 15 (data): va=0xf8c0 size=2097152 Segment 16 (data): va=0x8d00 size=2097152 Segment 17 (data): va=0xe300 size=2097152 Segment 18 (data): va=0xa5e0 size=2097152 Segment 19 (text): va=0xff80 size=2097152 Segment 20 (text): va=0xc3a0 size=2097152 Segment 21 (text): va=0x9d40 size=2097152 Segment 22 (text): va=0xc360 size=2097152 Segment 23 (text): va=0xca80 size=2097152 Segment 24 (text): va=0xe8e0 size=2097152 Segment 25 (text): va=0xc5e0 size=2097152 Segment 26 (text): va=0xf6a0 size=2097152 Segment 27 (text): va=0xec80 size=2097152 Segment 28 (text): va=0xc660 size=2097152 Segment 29 (text): va=0x85a0 size=2097152 Segment 30 (rodata): va=0xdb00 size=2097152 Segment 31 (rodata): va=0xfac0 size=2097152 Segment 32 (rodata): va=0x8e60 size=2097152 Segment 33 (rodata): va=0xb840 size=2097152 Segment 34 (rodata): va=0x9440 size=2097152 KASLR, boot 2 Segment 0 (text): va=0xb700 size=2097152 Segment 1 (rodata): va=0xc1b36000 size=4096 Segment 2 (rodata): va=0xc740 size=2097152 Segment 3 (rodata): va=0xe7e0 size=2097152 Segment 4 (rodata): va=0x93453000 size=4096 Segment 5 (rodata): va=0xa426 size=4096 Segment 6 (rodata): va=0x862c7000 size=4096 Segment 7 (rodata): va=0xd8681000 size=4096 Segment 8 (rodata): va=0xaec34000 size=4096 Segment 9 (rodata): va=0xdba5e000 size=4096 Segment 10 (rodata): va=0x8e14c000 size=4096 Segment 11 (rodata): va=0xb2cbc000 size=4096 Segment 12 (rodata): va=0xa5a5e000 size=4096 Segment 13 (rodata): va=0xdc716000 size=4096 Segment 14 (rodata): va=0x96f8b000 size=4096 Segment 15 (data): va=0xd1e0 size=2097152 Segment 16 (data): va=0xcec0 size=2097152 Segment 17 (data): va=0xec40 size=2097152 Segment 18 (data): va=0xc3e0 size=2097152 Segment 19 (text): va=0x92c0 size=2097152 Segment 20 (text): va=0x8c20 size=2097152 Segment 21 (text): va=0x9a20 size=2097152 Segment 22 (text): va=0xa460 size=2097152 Segment 23 (text): va=0xe9a0 size=2097152 Segment 24 (text): va=0xab60 size=2097152 Segment 25 (text): va=0xd3c0 size=2097152 Segment 26 (text): va=0x8340 size=2097152 Segment 27 (text): va=0xf120 size=2097152 Segment 28 (text): va=0xd240 size=2097152 Segment 29 (text): va=0xc900 size=2097152 Segment 30 (rodata): va=0xaf80 size=2097152 Segment 31 (rodata): va=0xacc0 size=2097152 Segment 32 (rodata): va=0xae60 size=2097152 Segment 33 (rodata): va=0xf160 size=2097152 Segment 34 (rodata): va=0xad00 size=2097152 > > Why does GENERIC_KASLR disable KDTRACE_HOOKS? Is this necessary, or > > are KDTRACE_HOOKS lowering the security somehow? > > In fact, it's because KDTRACE_HOOKS wants to parse one CTF section; but with > our implementation we have several of them, and KDTRACE_HOOKS does not > handle that. Chuck's patch for better ZFS/DTRACE support includes parsing of multiple CTF sections, intended for use with kernel modules (so that each kernel module can include its CTF). Will that be sufficient for KASLR? Thanks, Thomas # $NetBSD: Makefile,v 1.1 2016/
Spectre
Hi folks. Spectre is also a vulnerability. It's been discussed in the context of web browsers, but it does have repercussions for kernel. The gist of it seems to be, if you have code that looks like this: Variant 1: if (malicious offset is safe) value = array[malicious_offset]; value2 = (value & 1) value3 = array2[value2] You can read arbitrary memory, as cached memory will be faster. repeat this bit by bit. Variant 2: relies on poisoning the branch predictor if_transmit = mydriver_transmit; .. regular code if_transmit(); /* indirect call */ .. malicious_ptr: value = array[malicious_offset]; value2 = (value & 1) value3 = array2[value2] Now, we poison the branch target buffer, to predict that if_transmit = malicious_ptr. It does not even appear like a possible code path, but it is. This means that code being loaded is enough to pose a risk, even if there is no easy path to it. Some things that help this: - Rather than look for a gadget like this, they went for eBPF, which is like dtrace. It also has a JIT. You can load bytecode and it will verify and execute it. So you can make your own speculation-gadget. - Some archs do not allow fine-grained cache control like x86 clflush, but this isn't necessary for abuse. just fill the cache before going. they have done similar from JavaScript. Some that harm it: - Even speculative execution obeys access restrictions, so SMEP, SMAP, marking memory NX will prevent execution. - Instructions like 'lfence' stop speculative execution. - Intel and AMD have pushed microcode updates that introduce instructions, for Intel they are 'IBPB' and 'IBRS'. - ARM has 'BPIALL' to invalidate the branch target to stop branch predictor poisoning - Retpoline, stuff_RSB etc. to modify jumps to be less likely to jump into user-controlled code. People seemed to occasionally mentioned that 'as many as 100 instructions will be executed speculatively', so that is how far we are talking. Own thoughts: - Variant 1 seems possible to avoid with low cost. It will likely result in an error somewhere along the line, which is detectable. Flushing the entire cache on userret will make it hard to exploit. Do all bound checks failing result in an easily noticed error? - Variant 2 however is harder without custom instructions. Those may rely on a CPU being new enough to receive microcode updates, and them being applied. - I'm not sure how easy it is to find a good enough gadget without something like eBPF, but the mere presence of the code in memory was a risk. - Linux could've marked eBPF non-executable when it is unused, so its presence in memory does not pose risk. Discuss.
Re: Spectre
On Thu, Jan 18, 2018 at 12:37:11AM +, co...@sdf.org wrote: > - Intel and AMD have pushed microcode updates that introduce > instructions, for Intel they are 'IBPB' and 'IBRS'. + STIBP for Intel. > - I'm not sure how easy it is to find a good enough gadget without > something like eBPF Lua is probably a good target (though we don't normally have it loaded).
Re: Spectre
> I'd suggest reading the papers describing spectre and meltdown. They are fairly readable - I would expect anyone working on the NetBSD kernel to be competent to understand them - and they describe the vulnerabilities, and how the authors exploited them, in reasonable detail. Unfortunately, they appear to be exported only on the Web, and even then only over HTTPS. I can send copies privately to anyone for whom those are obstacles (probably not very many, but they were for me). https://spectreattack.com/ and https://meltdownattack.com/ are the URLs I've found, though (as implied above) I haven't actually verified them myself. > Spectre is also a vulnerability. > - Even speculative execution obeys access restrictions, In some respects. Meltdown is possible because Intel spec ex does not obey access restrictions in one particular respect; I don't know what aspects may not be obeyed by what CPUs except for that. > - Variant 1 seems possible to avoid with low cost. It will likely > result in an error somewhere along the line, which is detectable. Sometimes. Doing the operation inside a transaction apparently will suppress the memory fault in at least some cases. Executing the whole thing under spec ex of a mispredicted branch definitely will annul the trap, but, from reading the papers, it appears they haven't tested it, so it's speculation (hah), albeit reasonable speculation, that it would be exploitable that way. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Spectre
> On Jan 17, 2018, at 8:08 PM, Mouse wrote: > > ... >> - Even speculative execution obeys access restrictions, > > In some respects. Meltdown is possible because Intel spec ex does not > obey access restrictions in one particular respect; I don't know what > aspects may not be obeyed by what CPUs except for that. Indeed. I was surprised, but apparently that "obeys..." is wrong in the case of Intel, though it is correct, as you might expect, for AMD and ARM and probably most other architectures. More precisely, speculative execution obeys access restrictions in the sense that no architecturally visible (i.e., register/memory) changes occur that are prohibited by the access controls. But Intel does launch a speculative load without checking access; apparently the access check is done in parallel and will complete a while later, by which time the speculatively loaded data is in the cache and some other operations may be done based on it. Obviously, if speculative loads check permissions prior to launching the load, the issue goes away. If so, Meltdown is completely prevented. Spectre is unrelated and does not depend on a mistake of this kind, since there you're dealing with speculative loads that ARE permitted as far as access control goes; they just aren't wanted because they are preceded by range checks or the like. paul
Re: Spectre
On Wed, Jan 17, 2018 at 08:08:06PM -0500, Mouse wrote: > Unfortunately, they appear to be exported only on the Web, and even > then only over HTTPS. I can send copies privately to anyone for whom > those are obstacles (probably not very many, but they were for me). > https://spectreattack.com/ and https://meltdownattack.com/ are the URLs > I've found, though (as implied above) I haven't actually verified them > myself. Hi Mouse, 'wget -r' is often effective at fetching the contents of websites. It handles this website. If the problem is the website it might help.
Re: /dev/ksyms permissions
On Wed, Jan 17, 2018 at 07:19:32PM +0100, Anders Magnusson wrote: > libkvm uses it to get the kernel symbol namelist instead of reading /netbsd > for it (originally kvmdb, which was retired when ksyms was added). > Programs like ps, netstat etc... uses it to find in-kernel stuff, so you > cannot change it to require root privs to be read. > Maybe group kmem read, but that might require more elevated privileges in > the programs that uses ksyms. Thanks for the heads up. I was wondering if I missed an obvious non-root user.
Re: Spectre
On Thu, Jan 18, 2018 at 12:37:11AM +, co...@sdf.org wrote: > - Variant 1 seems possible to avoid with low cost. It will likely result > in an error somewhere along the line, which is detectable. Flushing > the entire cache on userret will make it hard to exploit. Do all > bound checks failing result in an easily noticed error? On further thought, this won't be sufficient protection. It only protects assuming we: - Cache memory - Time access to memory - Flush cache - Time access to now cached memory Flushing on userret/kernel entry is not sufficient because I am assuming it will need a second trip to userland. it does not, assuming we can construct our own perfect gadget.
Re: Spectre
> Spectre is unrelated and does not depend on a mistake of this kind, > since there you're dealing with speculative loads that ARE permitted > as far as access control goes; they just aren't wanted because they > are preceded by range checks or the like. Yes. I'm of two minds whether it's even fair to call spectre variants like that a vulnerability. (Spectre variants that exfiltrate values from other processes, or from the kernel, are quite another story.) On the one hand, of course, it is, in that it can be used to do things like read outside sandboxes. But, on the other hand, I can easily imagine a CPU designer looking at it and saying "What's the big deal if this code can read that location? It can get it anytime it wants with a simple load instruction anyway.", something I have trouble disagreeing with. So, I'm not sure whether I consider those spectre variants a CPU bug or just a misfeature that makes sandboxing more difficult (in that it provides unobvious ways to read memory). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Spectre
It's a lot less obvious from a CPU designer perspective. One will make the speculative bits, declare 'all the actions I do are rolled back, so this is perfectly safe!' and someone else making the cache doesn't realize that the reads were speculative and their effects should have been rolled back. People were talking about timing attacks for a while, but somehow it hadn't clicked that: array[*malicious_address & 1] Actually leaks (via timing) the content of the first bit of malicious_address. Or maybe it's just hadn't for me.