Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
Most people do not realize that any program they run can examine the memory
of any other process run by them. Meaning the computer game you are
running on your desktop can watch everything going on in Firefox or a
programs like pwsafe or kinit or other program that attempts to hide
passwords..
-- Dan Walsh
So, if we receive a block less than 10 seconds after the previous one
and the previous block had a timestamp more than 24 hours in the past,
we don't bother to verify any of the ECDSA signatures in it and will
allow it to include transactions that spend random people's Bitcoins!
-- Aidan Thornton(Log in to post comments)
Processes snooping others' memory Posted Feb 2, 2012 11:12 UTC (Thu) by epa (subscriber, #39769) [Link] Most people do not realize that any program they run can examine the memory of any other process run by them.Yup, I didn't realize that! I thought each process was isolated and that if you wanted to do shared memory then both processes had to give permission. It makes a lot of sense to disable ptrace and debugging another process unless the other process was specifically started as a child process of the debugger. If you want to debug a running process, some sort of confirmation (such as a secure key sequence typed at the local console) should be required. Before everyone jumps in to point out that they use ssh and so there is no local console, it is quite possible (in principle) to implement a secure key sequence across ssh too. When the user requests it the ssh client sends an out-of-band message to the server. Some remote login programs for Windows have a menu item 'Send Ctrl-Alt-Delete' and this is similar. Prompting the user to type his or her password also works, but I would prefer not to condition users into typing their password at the slightest provocation. There needs to be something a bit less severe than that but still requiring some confirmation step: press SysRq to allow the debugger to attach to this process.
Processes snooping others' memory Posted Feb 3, 2012 21:29 UTC (Fri) by mgedmin (subscriber, #34497) [Link]
*nod*
Ubuntu carries a kernel patch, I believe (I don't think it was accepted upstream -- or was it?), which disables ptrace for processes other than your children. So you can use gdb ./program or strace program, but not gdb progam pid or strace -p pid. Unless you become root or tune a sysctl knob.
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHarden...
Processes snooping others' memory Posted Feb 3, 2012 22:43 UTC (Fri) by raven667 (subscriber, #5198) [Link]
It seems like there is a lot of security issues related in some way to tracing, I wonder if it would be better to just disable tracing entirely by default and only allow it when explicitly configured by the admin.
Processes snooping others' memory Posted Feb 5, 2012 21:25 UTC (Sun) by quotemstr (subscriber, #45331) [Link]
Disabling tracing just provides a false sense of security. A user can do all sorts of things to affect the operation of a program you run under his user account --- things beyond tracing. It's not possible to enumerate all the possible vectors here.
There's a reason we trust *accounts*, not *programs*. When you start making trust decisions based on what executable image is running in a particular process, then, assuming you've done everything *else* right, you've still essentially turned every program into a setuid program. It'd be a security nightmare.
Now, since we agree that the trust principal has to be the user account, can we agree further that allowing a user to ptrace his own programs is harmless? I don't want any system that has this ptrace-only-children patch: tracing other programs is useful, and eliminating this capability doesn't add any real security.
Processes snooping others' memory Posted Feb 5, 2012 22:37 UTC (Sun) by k8to (subscriber, #15413) [Link]
The problem with the mentality of "I'm not a developer, I never troubleshoot stuff" is that sometimes your production stuff needs debugging.
If it's disabled by default, how can it be enabled? If it's a user action then a program could just do that to, so it's no security. If it's a root action, well fine but this has a goal of diabling it also for root (where it would again be no security, just a nuisance).
So what would be necessary to enable debugging of your own program if you can't by default if the program is already running before you start the debugger? Forms filled out in triplicate?
I just can't see how this can afford any useful functionality, and I can see how it will make real world problem analysis far less viable. There's a problem going on now... I guess we should file a request with the security group to allow it to be investigated?
Processes snooping others' memory Posted Feb 6, 2012 4:31 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I think you are overstating the inconvience of changing the default to disable ptrace. I'm not proposing this to be difficult, it just seems ptrace is a critical part of a lot of security issues so putting a safety on the feature might result in a few less people getting their feet blown off. Maybe I'm overstating the risk or the benefit but the practical inconvience seems very minor, if this is an insurmountable hurdle in your organization that sounds more like a people problem than a technical one.
At the very least we should be able to discuss this on the merits and come up with better reasons why its a bad idea than "it's too hard"
Processes snooping others' memory Posted Feb 6, 2012 4:34 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
"It's too hard" is a strawman. My point is that disabling ptrace doesn't add any extra security because there's no security *anyway* between processes two running with the same credentials. We learned 30 years ago to trust accounts, not programs, but we seem to have forgotten this lesson.
What attacks are defeated by disabling ptrace?
Processes snooping others' memory Posted Feb 6, 2012 6:30 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I just did a quick google search for "ptrace vulnerability Linux" and got a page full of all different CVE numbers. Maybe putting extra safety around ptrace is a bad idea but it does seem to have had more than its fair share of issues.
Processes snooping others' memory Posted Feb 6, 2012 8:00 UTC (Mon) by k8to (subscriber, #15413) [Link]
As stated below, it's a bit of fluff in the face of "no actual security improvement", but it's the difference between being able to actually fix things and not being able to, in the enterprise world. This has more to do with social factors than technology, but it's true nonetheless.
However, there's a better reason, which is unless you prevent it from being switched on again, it offers no security at all.
Only-root-can-enable would be a good policy. Using selinux-like functionality to limit access to known programs that have good reasons for it like gdb and strace might be a good idea.
But to turn it off for security, for root, is kind of silly, since root should be able to turn it on. The other choice of doing something like requiring a reboot to turn it on is possible, but then we're back at my point above where real problems will be unfixable because of this design choice.
Processes snooping others' memory Posted Feb 6, 2012 19:57 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I agree that an SELinux policy with ptrace off by default and only root can enable seems reasonable but I would say that blocking it for root isn't a total loss. It's a simpler policy, its either on or its off without root being an exception and its an extra step, that generates a policyload log notice, that might trip up an attacker but add no overhead for the legit admin. Of course expecting a security permission to contain root when root can just change the security policy is weak sauce.
Processes snooping others' memory Posted Feb 6, 2012 11:31 UTC (Mon) by epa (subscriber, #39769) [Link] There's a reason we trust *accounts*, not *programs*It depends on whether you consider a set of SELinux permissions to be an 'account'. Surely it is reasonable to have certain processes running as user fred with limited permissions. That might be considered a sub-account or subset of fred, just as fred could be thought of as a subset of root. You are probably right that there are a hundred and one other vectors of attack besides tracing. I would prefer to see an application such as xterm or the window manager run with a restricted set of permissions so that it cannot write files outside its own preferences directory - and more complex applications using a privileged save dialogue box so that they can write into a directory only when the user has specifically selected it. Then an exploit in, say, LibreOffice, would not give unrestricted access to the rest of the account. In the absence of these other security measures, forbidding ptrace might not do much in itself. I don't think anyone advocates making decisions based on what executable image is running in a process. It's about allowing the user more control over what permissions programs run with, and choosing sensible defaults for it. (Anyone who wants to use a debugger is quite capable of enabling the ptrace permission, but nontechnical users are not able to turn it off. This suggests optimizing for the nontechnical use case.)
Processes snooping others' memory Posted Feb 6, 2012 19:22 UTC (Mon) by fuhchee (subscriber, #40059) [Link]
The problem is meshing "There's a reason we trust *accounts*, not *programs*" and "can we agree further that allowing a user to ptrace his own programs is harmless". It's not a user/account ptracing his own programs. It's a *program* ptracing other programs.
Processes snooping others' memory Posted Feb 6, 2012 20:27 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
> It's not a user/account ptracing his own programs. It's a *program* ptracing other programs.
A program by necessity runs with some user account credentials. My point is that it's useful to look at security at the boundaries between accounts, but looking at security at the boundaries between processes in the same account (SELinux aside) is futile and dangerous.
Processes snooping others' memory Posted Feb 12, 2012 4:54 UTC (Sun) by zooko (subscriber, #2589) [Link]
The Capsicum project, now deployed in FreeBSD (https://plus.google.com/108313527900507320366/posts/8S1HF... ) seems to be offering a way to encapsulate your code so that if there is a bug in your code which allows it to be taken over by an attacker, it is still limited in the amount of damage it can do. The tricky part is to achieve this while not limiting the amount of good it can do when it is behaving properly. Capsicum sounds like a promising approach to that.
One good argument for enforcing security boundaries between programs (when possible) is the topic of the original story here: it is what users and programmers expect! Security mechanisms work best when they do what users and programmers think they do.
There's apparently no reason in principle that Capsicum couldn't be ported to Linux.
Processes snooping others' memory Posted Feb 7, 2012 0:52 UTC (Tue) by kees (subscriber, #27264) [Link]
Yeah, it's too bad Fedora isn't just using Yama. It solves a number of problems they're going to run into (crash handlers). I think it could be nice to add the ptrace logic to SELinux policy, but I don't think it's wise to use it the way they're planning.
http://www.outflux.net/blog/archives/2012/02/06/use-of-pt...
Processes snooping others' memory Posted Feb 9, 2012 10:09 UTC (Thu) by renox (subscriber, #23785) [Link]
> Most people do not realize that any program they run can examine the memory of any other process run by them.
*most* program true, but I know at least one webbrowser which is clever enough to sandbox itself ;-)
|
|||||||||||||