There is a Slashdot discussion today titled "Cambridge Researcher Breaks OpenBSD Systrace". Slashdot anonymous member has a comment "Even Sun''s Dtrace might be vulnerable." I don''t think it is. Comments? Exploiting Concurrency Vulnerabilities in System Call Wrappers http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdf Abstract System call interposition allows the kernel security model to be extended. However, when combined with current operating systems, it is open to concurrency vulnerabilities leading to privilege escalation and audit bypass. We discuss the theory and practice of system call wrapper concurrency vulnerabilities, and demonstrate exploit technques against GSWTK, Systrace, and CerbNG.
On Thu, Aug 09, 2007 at 11:01:03AM -0700, Vijay.Balakrishna at Sun.COM wrote:> There is a Slashdot discussion today titled "Cambridge Researcher Breaks > OpenBSD Systrace". Slashdot anonymous member has a comment "Even Sun''s > Dtrace might be vulnerable." I don''t think it is. Comments? > > Exploiting Concurrency Vulnerabilities in System Call Wrappers > http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdfThere was an internal-mailing-alias discussion about this. Please note the Abstract below:> Abstract > System call interposition allows the kernel security model to be > extended. However, when combined with current operating systems, it is > open to concurrency vulnerabilities leading to privilege escalation and > audit bypass. We discuss the theory and practice of system call wrapper > concurrency vulnerabilities, and demonstrate exploit technques against > GSWTK, Systrace, and CerbNG.DTrace doesn''t do system-call interposition... period. They use pre-deployed probes that get enabled/disabled as appropriate. Of course, I''ll let one of bmc, mws, or ahl further elaborate on this (or correct me). Dan
On Thu, Aug 09, 2007 at 11:01:03AM -0700, Vijay.Balakrishna at Sun.COM wrote:> There is a Slashdot discussion today titled "Cambridge Researcher Breaks > OpenBSD Systrace". Slashdot anonymous member has a comment "Even Sun''s > Dtrace might be vulnerable." I don''t think it is. Comments? > > Exploiting Concurrency Vulnerabilities in System Call Wrappers > http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdf > Abstract > System call interposition allows the kernel security model to be > extended. However, when combined with current operating systems, it is > open to concurrency vulnerabilities leading to privilege escalation and > audit bypass. We discuss the theory and practice of system call wrapper > concurrency vulnerabilities, and demonstrate exploit technques against > GSWTK, Systrace, and CerbNG.Absolutely not. DTrace is NOT a wrapper along those lines, nor is DTrace ever billed as a framework for building such wrappers. DTrace is robust in a sense that makes it quite unreliable for security purposes: it is designed not to unduly burden a production system. DTrace can and does drop events, which means it''s utterly unreliable as a framework for auditing. And DTrace probe context cannot resolve page faults, which means that it isn''t always possible to get at system call arguments from DTrace syscall entry probes; this too make it utterly unreliable as a framework for building security features. Yet those are features that make DTrace a safe tool to use for _tracing_ code in production systems. Nico --
On Thu, Aug 09, 2007 at 11:01:03AM -0700, Vijay.Balakrishna at Sun.COM wrote:> There is a Slashdot discussion today titled "Cambridge Researcher Breaks > OpenBSD Systrace". Slashdot anonymous member has a comment "Even Sun''s > Dtrace might be vulnerable." I don''t think it is. Comments? > > Exploiting Concurrency Vulnerabilities in System Call Wrappers > http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdfFirst, DTrace is not at all like Systrace -- it is not a "system call wrapper", but rather an instrumentation framework. That is, DTrace is not seeking to audit or augment flow, but merely make that flow observable. So DTrace is not -- and cannot be -- "vulnerable" in this sense whatsoever. Now, the core issue is that Systrace and these other wrappers are -- apparently -- validating indirect arguments on entry to system call. That is, I pass in a pointer, they do the copyin, validate the arguments with some additional security checks and then -- if I pass -- allow me to continue to the system call implementation -- but _with_ _my_ _original_ _pointer_. The idea that this is secure is laughable, for exactly the reason outlined in the paper: I can create another thread in my process that changes my arguments after you audit them. (I mean, duh.) It''s astonishing to me that _anyone_ could _possibly_ think that this constitutes a secure system -- I would expect a senior undergraduate in computer science to be able to point out the clear vulnerability here to concurrency. (Perhaps Systrace and its ilk were written by high school or elementary school students?) Not a DTrace issue, at any rate... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
On Thu 09 Aug 2007 at 11:17AM, Bryan Cantrill wrote:> Now, the core issue is that Systrace and these other wrappers are -- > apparently -- validating indirect arguments on entry to system call. That > is, I pass in a pointer, they do the copyin, validate the arguments with > some additional security checks and then -- if I pass -- allow me to > continue to the system call implementation -- but _with_ _my_ _original_ > _pointer_. The idea that this is secure is laughable, for exactly the > reason outlined in the paper: I can create another thread in my process > that changes my arguments after you audit them. (I mean, duh.) It''s > astonishing to me that _anyone_ could _possibly_ think that this > constitutes a secure system -- I would expect a senior undergraduate in > computer science to be able to point out the clear vulnerability here to > concurrency. (Perhaps Systrace and its ilk were written by high school > or elementary school students?)Maybe I have a new interview question to ask. :) And customers have a new question which they should be asking their kernel software vendors-- if you purchase a product which does system call wrapping for security policy enforcement, emulation, etc. you should inspect it with extreme caution. The next question which I assume will be asked is: is Zones and/or BrandZ vulnerable? I believe not, as Zones security is provided largely by Solaris''s fine-grained privilege mechanism. With respect to BrandZ-- it does implement a form of syscall interpositioning, but system call emulation is largely deferred to userland, which nicely sidesteps this as a security problem. You could certainly have a thread which overwrites a buffer while the wrapper was executing, but that would merely introduce a correctness problem within the application. -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
>There is a Slashdot discussion today titled "Cambridge Researcher Breaks >OpenBSD Systrace". Slashdot anonymous member has a comment "Even Sun''s >Dtrace might be vulnerable." I don''t think it is. Comments?It''s not the same type of mechanism at all so I''m not sure "vulnerable" is the appropriate term. However, any DTrace script which uses copyin() can be lied to, but that is a given. It''s strange that Systrace was broken because it seems the exact same problem I talked to the Systrace folks about several (more than five?) years ago. Casper
>Now, the core issue is that Systrace and these other wrappers are -- >apparently -- validating indirect arguments on entry to system call. That >is, I pass in a pointer, they do the copyin, validate the arguments with >some additional security checks and then -- if I pass -- allow me tocontinue to the system call implementation -- but _with_ _my_ _original_>_pointer_. The idea that this is secure is laughable, for exactly the >reason outlined in the paper: I can create another thread in my process >that changes my arguments after you audit them. (I mean, duh.) It''s >astonishing to me that _anyone_ could _possibly_ think that this >constitutes a secure system -- I would expect a senior undergraduate in >computer science to be able to point out the clear vulnerability here to >concurrency. (Perhaps Systrace and its ilk were written by high school >or elementary school students?)Indeed; and perhaps it''s their old school singe threaded mind set that allowed this in the first place. I mentioned this exact problem to them *years* ago and they claimed it was fixed in the new version (which I could not find at the time)>Not a DTrace issue, at any rate...Well, it is in the sense that copyin() data in DTrace is not necessarily the same data the system call operates on. Casper
On Thu 08/09/07 at 11:39 AM, dp at eng.sun.com wrote:> The next question which I assume will be asked is: is Zones and/or > BrandZ vulnerable? I believe not, as Zones security is provided > largely by Solaris''s fine-grained privilege mechanism. > > With respect to BrandZ-- it does implement a form of syscall > interpositioning, but system call emulation is largely deferred to > userland, which nicely sidesteps this as a security problem. You could > certainly have a thread which overwrites a buffer while the wrapper was > executing, but that would merely introduce a correctness problem within > the application.BrandZ turns Linux system calls into Solaris system calls. Those Solaris calls and their arguments are subject to exactly the same security checks as for a native Solaris application. We do some argument checking in userspace before issuing the Solaris system call, and (as you noted) it is certainly possible for an application to modify those arguments in the period between our verification and the execution of the system call. However, none of that argument checking is security related. The worst that could happen is that such an application would cause itself to crash or possibly corrupt its own data. I haven''t RTFA, but if Bryan''s summary is fair and accurate, the conclusion seems so obvious that I find it hard to believe that TFA needed to be written in the first place. Nils
That''s a really interesting point. I''m trying to learn how this mechanism works exactly. Is the source code the only guide to the Dtrace internal? What can be done to make Dtrace more suitable for security/auditing or is it just not possible due to the design of Dtrace? -- This message posted from opensolaris.org
I don''t think DTrace can be made more suitable for security auditing because that would cause it to lose the properties that make it safe to use. A security/auditing system must not drop events; DTrace must drop events when it is overwhelmed or the system will fail. Casper