| |||||||||||||
Stable kernel 2.6.25.11Stable kernel 2.6.25.11Posted Jul 15, 2008 2:00 UTC (Tue) by PaXTeam (subscriber, #24616)In reply to: Stable kernel 2.6.25.11 by adobriyan Parent article: Stable kernel 2.6.25.11
> You've missed similar commit re /proc/*/clear_refs . i didn't, i was reflecting on pagemap, not clear_refs. > Regardless, RTFS before making such statements. which one? i see you aren't disputing that the commit fixed security bugs for .26, you're only complaining about its applicability to .25. clearly, features not used on .25 are irrelevant, however the kmalloc(0) case is an interesting one as it ends up down a similar path to what the vmsplice exploit abused, save for the hardening of get_user_pages that was introduced due to the same. were cliph to withhold that bug for a little longer, you would be essentially arguing for not fixing an exploitable bug - not the right mindset i'm afraid. and let's not get started on the sillyness of using a userland address for ZERO_SIZE_PTR. another problem you haven't caught is that while get_user_pages brings in the userland buffer and even makes it writable, as soon as the mmap semaphore is dropped, the whole thing can disappear (munmap) or become read-only again (fork/mprotect) and thus whatever the whole exercise was supposed to prevent (sleeping on put_user? copy-on-write?) is still possible. > How old are you? judging from your post, probably at least 2-3 times your age. ;)
(Log in to post comments)
Stable kernel 2.6.25.11 Posted Jul 15, 2008 11:30 UTC (Tue) by adobriyan (guest, #30858) [Link] > > Regardless, RTFS before making such statements. > > which one? 2.6.25 obviously. > i see you aren't disputing that the commit fixed security bugs for .26, Correct, but irrelevant. Bugs were added in 2.6.26-rc7. kmalloc(0) is harmless. Multiplication overflow on 64-bit can't happen (honestly, I'm not sure about 32-bit, haven't checked personally). Just, stating something, state full picture. > you're only complaining about its applicability to .25. Oh, wow! It's you who is complaining here, dammit! > clearly, features not used on .25 are irrelevant, PROC_PAGE_MONITOR is enabled in 2.6.25, so it's relevant. What feature is irrelevant but relevant to thread? > however the kmalloc(0) case is an interesting one as it ends up down a > similar path to what the vmsplice exploit abused, save for the hardening > of get_user_pages that was introduced due to the same. were cliph to > withhold that bug for a little longer, you would be essentially arguing > for not fixing an exploitable bug - not the right mindset i'm afraid. Blame developers for bugs which could have happened. This is a solution! > and let's not get started on the sillyness of using a userland address > for ZERO_SIZE_PTR. Given that a) kmalloc() will return ZERO_SIZE_PTR, b) get_user_pages() will immediately return 0, let's not. > another problem you haven't caught When you've noticed this? Right after pagemap was added? After pagemap was shipped in 2.6.25? After you've noticed pagemap fixes? After you realized that some from all those pagemap fixes do not apply to 2.6.25 (crap!)? > is that while get_user_pages brings in the userland buffer and even > makes it writable, as soon as the mmap semaphore is dropped, the whole > thing can disappear (munmap) or become read-only again (fork/mprotect) > and thus whatever the whole exercise was supposed to prevent (sleeping > on put_user? Don't know what exact aspect of "sleeping on put_user" you mean. > copy-on-write?) is still possible. But, but, RTFS again. Notice put_page() calls in pagemap_read(). Why they're there? Probably, because get_user_pages() pins pages, so they won't dissapear from under you. Regarding mprotect(): user will clear PROT_WRITE, and kernel will put_user() to it. You know what will happen. Amazing hole. > > > business as usual, i guess. > > > > How old are you? > > judging from your post, probably at least 2-3 times your age. ;) Yes, yes, but... How old are you?
Stable kernel 2.6.25.11 Posted Jul 18, 2008 12:05 UTC (Fri) by PaXTeam (subscriber, #24616) [Link] Sorry Alexey to have you waited but as you probably saw, i was quite busy elsewhere ;). with that said, having seen your knowledge/idiocy ratio (no need to go further than say http://thread.gmane.org/gmane.linux.kernel/706524/focus=7...), i'll cut this answer short and just point out a few obvious things in the hope you'll think more next time before posting. > kmalloc(0) is harmless. it's not in general. it returns a non-NULL ptr so !ptr checks will not catch it and that can later result in their dereference of userland memory. in other words, it's a design error, this call should return something that's guaranteeed to fault on dereference. the kernel even has a special range for exactly this purpose: the negative error codes. > Multiplication overflow on 64-bit can't happen 2fc: 4d 29 fc sub %r15,%r12 2ff: 49 c1 ec 0c shr $0xc,%r12 303: 49 63 fc movslq %r12d,%rdi 306: 45 89 e5 mov %r12d,%r13d 309: 48 c1 e7 03 shl $0x3,%rdi 30d: e8 00 00 00 00 callq 312 <pagemap_read+0xc4> 30e: R_X86_64_PC32 __kmalloc+0xfffffffffffffffc do you know what movslq does? (extra quiz question: do you know why it's there at all?) do you understand what the following shl will do to the result? > Don't know what exact aspect of "sleeping on put_user" you mean. that other threads can schedule during that sleep and do all kinds of changes to the virtual address space (and consequently, the underlying physical pages as well) that this code may not have expected to happen. i don't know if that's the case, i was asking the question myself, but considering that someone went to lengths to call get_user_pages in this code, there must be a reason for it. > Notice put_page() calls in pagemap_read(). Why they're there? Probably, > because get_user_pages() pins pages, so they won't dissapear from under > you. it pins physical pages, it doesn't pin virtual memory mappings in place (that's what the mmap semaphore is for). so while the pinned pages may very well stay in RAM, the put_user may not access them at all if copy-on-write or munmap/mmap brought in a different set of physical (and quite possibly, not pinned) pages. whether that's a problem or not, i can't tell (read: i'm not going to spend any more time on this), hence the question. > Regarding mprotect(): user will clear PROT_WRITE, and kernel will > put_user() to it. You know what will happen. Amazing hole. if copy-on-write moves your carefully pinned page away and replaces it with a non-pinned one, an assumption this code relies (or may rely, we don't know as of now) on is broken. what consequences that has, i don't know, hence my question.
|
|||||||||||||