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: Tue, 07 Jun 2011 02:02:52 +0200 Message-ID: <4DED6AAC.12348.14E3578E@pageexec.freemail.hu> (raw) In-Reply-To: <20110606191218.GB20123@elte.hu> On 6 Jun 2011 at 21:12, Ingo Molnar wrote: > * firstname.lastname@example.org <email@example.com> wrote: > > 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)? > > That's what binary compatibility means, yes. so fedora is not binary compatible. did just admit that in real life security won out? we're on the right track! ;) > > 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 ;). > > It's a statistical security measure, and was such a measure from the > day it was committed: > > | commit e6e5494cb23d1933735ee47cc674ffe1c4afed6f > | Author: Ingo Molnar <firstname.lastname@example.org> > | Date: Tue Jun 27 02:53:50 2006 -0700 > | > | [PATCH] vdso: randomize the i386 vDSO by moving it into a vma > | > | Move the i386 VDSO down into a vma and thus randomize it. > | > | Besides the security implications, this feature also helps debuggers, which > | can COW a vma-backed VDSO just like a normal DSO and can thus do > | single-stepping and other debugging features. > > So what's your point? you called this feature "borderline security FUD" but have yet to prove it. on the contrary you did prove that it is a security feature and there's at least one distro where it matters. of course you can call fedora's and even mainline's vdso randomization FUD, but then please fix it and map it at a constant address. you wouldn't want to live with "borderline security FUD" features, would you? ;) > > > 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. > > Two arguments. > > Firstly, you generalize too much, it's only a security problem if you > actually have an attack surface: a security problem without an attack surface is an animal that doesn't exist. a potential problem becomes a security problem when there's a way to attack/abuse it. your security vocabulary is seriously lacking and/or you're very confused about very basic terminology but i'll try to do my best to make sense out of what you're trying to say and also correct it as needed. > Many Linux systems don't have any: non-networked appliances that > are not physically connected to any hostile medium. that only means that some problems are not security problems for those systems. i find it somewhat ironic that you accuse me of too much generalization yet you're the one who believes in black and white terms, such as 'security bugs'. let me clear up your profound confusion: pretty much every term in security is relative, of the 'it depends on this or that condition' kind. e.g., when we call something an exploitable bug it's because we know it can be exploited for sure under some conditions (given OS, given userland app, given config options, etc, whatever applies to the given situation) not because it cannot be exploited under some other conditions, duh. > For such a system a gaping root hole bug is *not even a bug*, while > a rare memory leak that you'd shrug off on a desktop might be a > showstopper. for such a system there's no 'gaping root hole' and we don't say that such a system 'has an exploitable bug but not really'. such categories may exist in your head only, but i can assure you that they don't exist among professionals. what's more, there're things that some consider as a feature while others consider a bug (or even security bug), then what ;). > Secondly, and more importantly, we try to maintain the kernel in a > way so that it can converge to a no bugs state in the long run. no, you're not doing that. you don't even know that such a state is a pipedream and cannot be achieved by any practical means we know of. i'm somewhat saddened (if true) that this is a driving idea among kernel developers. consider that before eliminating old bugs you'd better not let new ones in, in the first place. but you have no processes to ensure this, you don't even know how to do it or if it's even possible to pull off such a feat. > You can only do that by making sure that even in the very last > stages, when there are virtually no bugs left, the incentives and > mechanisms are still there to fix even those bugs. more pipedreams. do you have *any* idea what you're talking about? seriously, can you provide a program (think task list, not actual computer stuff) that you think will get you anywhere near to this goal? i bet you cannot. i bet you don't even know what the state of the art is in creating such systems (on the linux scale, not thousand line long specialized microkernels). > If we add obstruction features that turn bugs into less severe > statistical bugs then that automatically reduces the speed of > convergence. what? (you're still very confused about the bug vs. exploit thing btw, ASLR doesn't affect bugs, it affects exploit techniques) what's the connection again? you're just repeating what you said before without anything to back it up. one more time: intrusion prevention is orthogonal to bug finding & fixing. also for the latter group of people, you only really care about those that actually disclose to you what they find, and they are not influenced by exploit prevention techniques given how they're not interested in writing said exploits (else they would not disclose the bugs they're exploiting). > We might still do it, but you have to see and acknowledge that it's a > *cost*. i don't have to acknowledge non-existent things ;). you made up all this 'cost' thing and have yet to explain it. > You seem to argue that it's a bona fide bug and that the fix > is deterministic that it "needs fixing" - and that is wrong on both > counts. sorry i really lost you here. what bug are you talking about? and what's with the 'fix is deterministic'? what else can a fix be? you either fix a bug or you don't, as much as i hate black&white statements, i don't know how you can make bugfixing non-deterministic ;). i hope you're not mixing up ASLR (which works against exploit techniques) with bugfixing. > You generally seem to assume that security is an absolute goal with > no costs attached. quote me on that back please or admit you made this up. i'm very well aware of every security feature and its cost in PaX for example, i have written about them extensively and educated both users and non-users for over a decade now. if you want to paint me something do yourself a favour and at least read up on the project and person you're discussing. you can start with the PaX documentation, its kernel config help, grsec forum threads, etc. > > > 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). > > Which of these changes are deterministic? you tell me, you seemed to talk in generic terms without naming anything in particular, so i was left guessing and made a similarly generic statement ;). but to give you an idea here, my approach of making the vsyscall page nx is a deterministic approach. there's no randomness involved in that step. or Andy's approach of replacing the syscall insns (which can be found and executed from anywhere) with a specially chosen one is also a deterministic solution, there is no randomness involved in whether an attacker can or cannot abuse them. heck, you can consider having the vsyscall page at a fixed address as a deterministic help library for exploit writers. > Removing a syscall or a RET from a fixed address is *still* only a > probabilistic fix: the attacker can still do brute-force attacks > against the many executable pages in user-space, even if everything > is ASLR obfuscated. no, it's not a fix, you're once again confusing bugs with exploit techniques and bugfixes with exploit prevention techniques. other that that yes, you stated a tautology, the point of which was? > It helps if you read the bit i provided after the colon: > > > > if a bug is not exploitable then people like Spender wont spend > > > time exploiting and making a big deal out of them, right? > > If a bug is hidden via ASLR (and *all* of the changes in this thread > had only that effect) and can not be exploited using the simple fixed > address techniques disabled by these patches, then people like you or > Spender wont spend time exploiting them, right? you're really really confused about this whole bug/exploit thing. ASLR has nothing to do with bugs. it has everything to do with exploits and more precisely, exploit techniques. do you understand the difference between bugs and exploits? because if you do, you can't have made the above question, so i'm guessing you don't understand the difference, even if this is the most crucial point in understanding what all the intrusion prevention approach is about. ASLR prevents exploit techniques that rely on knowing addresses in the attacked process, regardless of the the underlying bug. from another angle, a bug may very well be exploitable by one exploit technique even under ASLR but not exploitable by another technique (obviously an exploit writer's job is to find out what the case is and choose wisely by considering all the factors). so what you wanted to say above but didn't know how to put it correctly is that given an exploit technique prevented (in a probabilistic sense) by ASLR, what would an exploit writer do (neither of us is, btw but your continued insistence on painting us as such shows how far detached you are from the world of computer security, i bet you can't even name a single company that actually trades in exploits and employs such people). and the answer to that is that 'it depends', as so many things do in security. it depends on, among others: - whether there's another bug that can leak back useful addresses - whether there's another exploit technique that doesn't need fixed addresses (think partial pointer overwrites for example) - whether the given target can sustain brute force or not - anything else that a real exploit writer (unlike us) would consider so your question has no black&white answer even if you'd like to get one, that's just the way things often are in security. > But it can still be exploited brute-force: just cycle through the > possible addresses until you find the right instruction that elevates > privileges. that's not true, at least not in systems that do ASLR properly and have a brute force prevention mechanism. there the probability can be bounded below 1 (did you even read the ASLR doc i wrote some 8 years ago? it's all explained there). > > 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 example after this meta-fix: > > c41d68a: compat: Make compat_alloc_user_space() incorporate the access_ok() > > We certainly have eliminated the class of bugs where we'd return > out-of-bounds pointers allocated via compat_alloc_user_space() and > exploited via large or negative 'len' values. it wasn't a class but a single instance of a bug. a class of bugs needs more instances. have you got any more of this kind? alternatively you can try and find your supposed class in the CWE, i'm all ears ;). > > > 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? [...] > > It was an generic/indefinite 'you'. > > To understand my point you need to look at the context i replied to: > > > > > 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. > > You claimed that it is a very real security problem. I pointed out > that this is not a real primary fix for some security bug ASLR was never about bugs, but exploit techniques, not sure where you read anything to the contrary from me. so 'citation needed'. or are you once again confusing bugfixes with intrusion prevention techniques? > but a statistical method that makes exploits of other bugs harder (but > not impossible), that's not true as explained above. > and as such it has the cost of making *real* fixes slower to arrive. yes, you keep saying that but you never presented any evidence why that would be the case. and you probably meant 'finding bugs' not 'fixing bugs' as it'd be a real shame if the kernel bug fixing process would depend on the presence of intrusion prevention mechanisms. as i pointed it out earlier, customers/userd don't take DoS that much more kindly either ;). > I don't think this was a terribly complicated argument, yet you do > not even seem to acknowledge that it exists. that's because your 'argument' is bogus. you imagine things and believe them to be true, without having even taken a look at real life out there. host-based intrusion prevention techniques are what, like little over a decade old? what do you think happened in all that timeframe with bugs? did they die out? or did more and more people jump on the bug finding bandwagon and eventually make the bug counts explode? what happened to the exploits over the same time frame? did they die out? or did their numbers explode? what happened to malware? etc, etc. you're so uninformed yet insist on playing the knowledgable one that one begins to wonder whether you have some psycholocigal issue with trying to be the smart person in every field of life. it should now be becoming clear to you that security won't be that field if you keep ignoring reality.
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 2011-06-06 19:12 ` Ingo Molnar 2011-06-07 0:02 ` pageexec [this message] 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=4DED6AAC.12348.14E3578E@pageexec.freemail.hu \ --email@example.com \ --cc=JBeulich@novell.com \ --cc=Louis.Rilling@kerlabs.com \ --cc=Valdis.Kletnieks@vt.edu \ --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 \ --firstname.lastname@example.org \ /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 \ email@example.com 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