From: firstname.lastname@example.org To: Ingo Molnar <email@example.com> Cc: Linus Torvalds <firstname.lastname@example.org>, Andy Lutomirski <email@example.com>, firstname.lastname@example.org, Thomas Gleixner <email@example.com>, firstname.lastname@example.org, Jesper Juhl <email@example.com>, Borislav Petkov <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Arjan van de Ven <firstname.lastname@example.org>, Jan Beulich <JBeulich@novell.com>, richard -rw- weinberger <email@example.com>, Mikael Pettersson <firstname.lastname@example.org>, Andi Kleen <email@example.com>, Brian Gerst <firstname.lastname@example.org>, Louis Rilling <Louis.Rilling@kerlabs.com>, Valdis.Kletnieks@vt.edu, Peter Zijlstra <email@example.com> Subject: Re: [PATCH] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS Date: Mon, 06 Jun 2011 20:04:49 +0200 Message-ID: <4DED16C1.24309.139B86C7@pageexec.freemail.hu> (raw) In-Reply-To: <20110606124743.GB22375@elte.hu> On 6 Jun 2011 at 14:47, Ingo Molnar wrote: > * firstname.lastname@example.org <email@example.com> wrote: > > [...] does that mean that you guys would accept a patch that would > > map the vdso at a fixed address for old times's sake? if not, on > > what grounds would you refuse it? see, you can't have it both ways. > > You can actually do that by enabling CONFIG_COMPAT_VDSO=y. as you noted later, we're talking about amd64 here. but ignoring that, let's see what you've just shown here. 1. why does CONFIG_COMPAT_VDSO exist? because you guys realized some time in the past, after several public exploits, that keeping known code at fixed addresses wasn't the brightest of ideas. so you implemented without much if any resistance vdso randomization and kept a backwards compatibility option for userland that knew better and relied on those fixed addresses. sound familiar? security issue with known code/addresses triggering move to randomization? right in this patch series! why lie about it then and paint it something else than what it is? oh yes, covering up security related fixes/changes is a long held tradition in kernel circles. 2. who enables CONFIG_COMPAT_VDSO? RHEL? Fedora? SLES? Debian? Ubuntu? (i don't know, i'm asking) and whoever enables them, what do you think they're more likely to get in return? some random and rare old binaries that still run for a minuscule subset of users or every run-of-the-mill exploit working against *every* user, metasploit style (did you know that it has a specific target for the i386 compat vdso)? so once again, tell me whether the randomized placement of the vdso wasn't about security (in which case can we please have it back at a fixed mmap'd address, since it doesn't matter for security you have no reason to refuse ;). > > the fixed address of the vsyscall page *is* a very real security > > problem, it should have never been accepted as such and it's high > > time it went away finally in 2011AD. > > It's only a security problem if there's a security hole elsewhere. it's not an 'if', there *is* a security hole 'elsewhere', else the CVE list had been abandoned long ago and noone would be doing proactive security measures such as intrusion prevention mechanisms. so it *is* a security problem. > The thing is, and i'm not sure whether you realize or recognize it, > but these measures *are* two-edged swords. they aren't, see below why. > Yes, the upside is that they reduce the risks associated with > security holes - but only statistically so. not sure what 'these measures' are here (if you mean ASLR related ones, please say so), some are randomization based (so their impact on security is probabilistic), some aren't (their impact is deterministic). > The downside is that having such a measure in place makes it somewhat > less likely that those bugs will be found and fixed in the future: i'm not sure i follow you here, it seems to me that you're mixing up bug finding/fixing with exploit development and prevention measures. these things are orthogonal to each other and neither affects the other unless they're perfect (which neither side is). i.e., if we could find all bugs, intrusion prevention and exploit writing would die out. or if we could exploit all bugs under any circumstances, intrusion prevention would die out. or if we could defeat all exploit techniques, exploit writing would die out, etc. but there's no such perfection in the real world. so you can go find and fix bugs without ever writing exploits for them or without ever implementing countermeasures against exploit techniques for a given bug class (actually, it's not even correct to put it this way, exploit techniques are orthogonal to bug classes, a bug can be exploited by several techniques and an exploit technique can be used against different kinds of bugs, so prevention mechanisms like ASLR are against techniques, not bugs, for the latter we have to do some kind of analysis/instrumentation). also not finding or fixing bugs in the presence of intrusion prevention mechanisms means that an exploited bug is (usually) transformed into a some kind of denial of service problem, not something you can go easy about if you have paying customers and/or vocal users. so having such measures is not reason to become lax about finding and/or fixing bugs. what these measures buy you (your customers/users, that is) are time and reduced risk of getting owned. > if a bug is not exploitable then people like Spender wont spend time > exploiting and making a big deal out of them, right? i'm not sure i get this example, if a bug is not exploitable, how could anyone possibly spend time on, well, exploiting it? btw, what's with this being fixed on specific individuals, circus and what not? do you seriously base your decision about fixing bugs whether you hear about them in the news? or are your collective egos being hurt by showing the world what kind of facade you put up when you talk about 'full disclosure' but cover up security fixes? also, i never understood the circus part, can you tell me what exactly you find in the security world as 'circus'? specific examples will do. > And yes, it might be embarrasing to see easy exploits and we might > roll eyes at the associated self-promotion circus but it will be one > more bug found, the reasons for the bug will be examined, potentially > avoiding a whole class of similar bugs *for sure*. it's a nice theory, it has never worked anywhere (just look at OpenBSD ;). show me a single class of bugs that you think you'd fixed in linux. for that you'd have to know about them, try CWE (not to be confused with CVE) in google. in the meantime i can tell you what you did not fix *for sure*: - use-after-free bugs - double free bugs - heap buffer overflows - stack buffer overflows - stack overflows (yes, it's not the buffer overflow kind) - refcount overflows (as a subset of user-after-free bugs) - integer overflows and wraparounds - information leaking from heap/stack areas - bugs resulting from undefined behaviour in C - resource exhaustion bugs - etc > Can you guarantee that security bugs will be found and fixed with the > same kind of intensity even if we make their exploitation (much) > harder? I don't think you can make such a guarantee. why would *i* have to guarantee anything? i'm not santa claus or something ;). i'm not even into the business of finding & fixing bugs, i, at most, fix stuff i (or users) run across while developing PaX but i don't go out of my way and audit the kernel (or anything else) for bugs. life's too short and i placed my bets long ago on intrusion prevention ;). but if you're speaking of a hypothetical 'you', i think i explained above why these processes are independent. also this particular feature (getting rid of the vsyscall) is a very small dent in the exploit writers arsenal, it's an anti-script kiddie measure at most and a feature box you can tick off when you talk about 'full ASLR'. real exploit writers will continue to find info leaking bugs, use brute forcing, heap/JIT spraying, and other techniques. > So as long as we are trading bugs-fixed-for-sure against statistical > safety we have to be mindful of the downsides of such a tradeoff ... while i'm still trying to put together the argument you're making, i hope you're not saying that leaving users in exploitable conditions is actually *better* for security...
next prev parent reply index Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-06-05 17:50 [PATCH v5 0/9] Remove syscall instructions at fixed addresses Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 1/9] x86-64: Fix alignment of jiffies variable Andy Lutomirski 2011-06-06 8:31 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 2/9] x86-64: Document some of entry_64.S Andy Lutomirski 2011-06-06 8:31 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 3/9] x86-64: Give vvars their own page Andy Lutomirski 2011-06-06 8:32 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 4/9] x86-64: Remove kernel.vsyscall64 sysctl Andy Lutomirski 2011-06-06 8:32 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-12-05 18:27 ` [PATCH v5 4/9] " Matthew Maurer 2011-06-05 17:50 ` [PATCH v5 5/9] x86-64: Map the HPET NX Andy Lutomirski 2011-06-06 8:33 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 6/9] x86-64: Remove vsyscall number 3 (venosys) Andy Lutomirski 2011-06-06 8:33 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 7/9] x86-64: Fill unused parts of the vsyscall page with 0xcc Andy Lutomirski 2011-06-06 8:34 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls Andy Lutomirski 2011-06-05 19:30 ` Ingo Molnar 2011-06-05 20:01 ` Andrew Lutomirski 2011-06-06 7:39 ` Ingo Molnar 2011-06-06 9:42 ` pageexec 2011-06-06 11:19 ` Andrew Lutomirski 2011-06-06 11:56 ` pageexec 2011-06-06 12:43 ` Andrew Lutomirski 2011-06-06 13:58 ` pageexec 2011-06-06 14:07 ` Brian Gerst 2011-06-07 23:32 ` pageexec 2011-06-07 23:49 ` Andrew Lutomirski 2011-06-08 6:32 ` pageexec 2011-06-06 15:26 ` Ingo Molnar 2011-06-06 15:48 ` pageexec 2011-06-06 15:59 ` Ingo Molnar 2011-06-06 16:19 ` pageexec 2011-06-06 16:47 ` Ingo Molnar 2011-06-06 22:49 ` pageexec 2011-06-06 22:57 ` david 2011-06-07 9:07 ` Ingo Molnar 2011-06-07 6:59 ` Pekka Enberg 2011-06-07 8:30 ` Ingo Molnar 2011-06-07 23:24 ` pageexec 2011-06-08 5:55 ` Pekka Enberg 2011-06-08 6:19 ` pageexec 2011-06-08 6:48 ` Ingo Molnar 2011-06-08 9:02 ` pageexec 2011-06-08 9:11 ` Andi Kleen 2011-06-08 9:35 ` pageexec 2011-06-08 10:06 ` Andi Kleen 2011-06-08 10:26 ` pageexec 2011-06-08 10:39 ` Ingo Molnar 2011-06-08 10:35 ` Ingo Molnar 2011-06-08 9:15 ` Ingo Molnar 2011-06-08 7:16 ` Ingo Molnar 2011-06-08 9:29 ` pageexec 2011-06-06 14:01 ` Linus Torvalds 2011-06-06 14:55 ` pageexec 2011-06-06 15:33 ` Ingo Molnar 2011-06-06 15:58 ` pageexec 2011-06-06 15:41 ` Ingo Molnar 2011-06-06 8:34 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-06 8:35 ` [tip:x86/vdso] x86-64, vdso, seccomp: Fix !CONFIG_SECCOMP build tip-bot for Ingo Molnar 2011-06-07 7:49 ` [tip:x86/vdso] x86-64: Emulate legacy vsyscalls tip-bot for Andy Lutomirski 2011-06-07 8:03 ` tip-bot for Andy Lutomirski 2011-06-05 17:50 ` [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule Andy Lutomirski 2011-06-06 8:34 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 2011-06-06 8:46 ` [PATCH v5 9/9] " Linus Torvalds 2011-06-06 9:31 ` Andi Kleen 2011-06-06 10:39 ` pageexec 2011-06-06 13:56 ` Linus Torvalds 2011-06-06 18:46 ` pageexec 2011-06-06 20:40 ` Linus Torvalds 2011-06-06 20:51 ` Andrew Lutomirski 2011-06-06 21:54 ` Ingo Molnar 2011-06-06 21:45 ` Ingo Molnar 2011-06-06 21:48 ` Ingo Molnar [not found] ` <BANLkTi==uw_h78oaep1cCOCzwY0edLUU_Q@mail.gmail.com> 2011-06-07 8:03 ` [PATCH, v6] x86-64: Emulate legacy vsyscalls Ingo Molnar 2011-06-06 21:53 ` [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule pageexec 2011-06-06 14:44 ` Ingo Molnar 2011-06-06 15:01 ` pageexec 2011-06-06 15:15 ` Ingo Molnar 2011-06-06 15:29 ` pageexec 2011-06-06 16:54 ` Ingo Molnar 2011-06-06 18:59 ` pageexec 2011-06-06 19:25 ` Ingo Molnar 2011-06-07 0:34 ` pageexec 2011-06-07 9:51 ` Ingo Molnar 2011-06-07 23:24 ` pageexec 2011-06-10 11:19 ` Ingo Molnar 2011-06-14 0:48 ` pageexec 2011-06-15 19:42 ` Valdis.Kletnieks 2011-06-06 14:52 ` Ingo Molnar 2011-06-06 10:24 ` [PATCH] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS Ingo Molnar 2011-06-06 11:20 ` pageexec 2011-06-06 12:47 ` Ingo Molnar 2011-06-06 12:48 ` Ingo Molnar 2011-06-06 18:04 ` pageexec [this message] 2011-06-06 19:12 ` Ingo Molnar 2011-06-07 0:02 ` pageexec 2011-06-07 9:56 ` Ingo Molnar 2011-06-07 23:24 ` pageexec 2011-06-09 6:48 ` Ingo Molnar 2011-06-09 23:33 ` pageexec 2011-06-07 10:05 ` Ingo Molnar 2011-06-07 23:24 ` pageexec 2011-06-09 7:02 ` Ingo Molnar 2011-06-09 23:33 ` pageexec 2011-06-07 10:13 ` Ingo Molnar 2011-06-07 23:24 ` pageexec 2011-06-06 12:19 ` Ted Ts'o 2011-06-06 12:33 ` Andrew Lutomirski 2011-06-06 12:37 ` Ingo Molnar 2011-06-06 14:34 ` [tip:x86/vdso] " tip-bot for Ingo Molnar 2011-06-05 20:05 ` [PATCH v5 0/9] Remove syscall instructions at fixed addresses Andrew Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4DED16C1.24309.139B86C7@pageexec.freemail.hu \ --firstname.lastname@example.org \ --cc=JBeulich@novell.com \ --cc=Louis.Rilling@kerlabs.com \ --cc=Valdis.Kletnieks@vt.edu \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git