Bug #35715 | Using SESSION_USER() in a view definition is unsafe | ||
---|---|---|---|
Submitted: | 31 Mar 2008 19:37 | Modified: | 1 Apr 2008 15:48 |
Reporter: | Lars Olson | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Views | Severity: | S2 (Serious) |
Version: | 5.0.51a | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[31 Mar 2008 19:37]
Lars Olson
[1 Apr 2008 10:19]
Sergei Golubchik
I tend to consider it not a bug. The situation boils down to simple "run a code written by an attacker and you're screwed", which is true in a general case. Bob could've created a function with SQL SECURITY INVOKER and execute any code he wants with Carol's credentials. For example, you exploit the fact that function leakInfo() is run with Bob's credentials but it sees SESSION_USER() of Carol. But there's no need to exploit it, Bob could've written: CREATE SQL SECURITY INVOKER VIEW picnic_view AS SELECT * FROM picnic WHERE exists (select bob.leakInfo(ssn, salary, email) from employee); In this case the view is executed with Carol's credentials, and only *after* the field values are selected (with Carol's credentials !!!) they're sent to Bob's function. In this case SESSION_USER() shows Carol, because the view is evaluated in Carol's security context, Bob is not involved here at all.
[1 Apr 2008 15:48]
Lars Olson
True. I think both examples put doubt into my mind that anyone can really be trusted, but as long as this isn't considered to be anything new, then I'm satisfied.