So whats up with the 11.2 java security hole?
in [Oracle]
|
From: John Hurley on 6 Feb 2010 18:47 Based on David Litchfield ... http://www.computerworld.com/s/article/9151318/Black_Hat_Zero_day_hack_of_Oracle_11g_database_revealed?taxonomyId=1
From: Vladimir M. Zakharychev on 7 Feb 2010 06:19 On Feb 7, 2:47 am, John Hurley <johnbhur...(a)sbcglobal.net> wrote: > Based on David Litchfield ... > > http://www.computerworld.com/s/article/9151318/Black_Hat_Zero_day_hac... Hmm... Off the top of my head: unprivileged user can execute external programs on the server from Java in context of Oracle owner user. If this is so, then it's trivial to create a script with GRANT DBA TO SCOTT in it and then execute 'sqlplus "/ as sysdba" @becomedba.sql'. Actually, the possibilities to compromise the system and its neighborhood further are limitless. Combined with some unauthenticated remote PL/SQL code execution exploit (for unpatched mod_plsql/OWA for example,) this hole is very dangerous indeed. You can grab whatever you please from such system or wreak havoc on it, map the internal network and its services, siphon data from nearby Oracle databases by creating DB links to them, etc. Before posting the above I quickly swept the net about this and found that Alex Kornbrust posted the details in his blog at http://blog.red-database-security.com/ and it's exactly this kind of attack. He also suggests the workaround (revoking EXECUTE from PUBLIC on certain Java-related packages.) Actually, I'd check the privileges on these packages and revoke EXECUTE from everyone else, too. SYS is just enough. By the way, DBMS_SCHEDULER has the capability to execute external programs, too. Hope default privileges for it are better thought out and it's locked tight out of the box... Regards, Vladimir M. Zakharychev N-Networks, makers of Dynamic PSP(tm) http://www.dynamicpsp.com
From: Maxim Demenko on 7 Feb 2010 07:24 On 07.02.2010 12:19, Vladimir M. Zakharychev wrote: > On Feb 7, 2:47 am, John Hurley<johnbhur...(a)sbcglobal.net> wrote: >> Based on David Litchfield ... >> >> http://www.computerworld.com/s/article/9151318/Black_Hat_Zero_day_hac... > > He also suggests the workaround (revoking EXECUTE from PUBLIC > on certain Java-related packages.) Actually, I'd check the privileges > on these packages and revoke EXECUTE from everyone else, too. SYS is > just enough. > > Regards, > Vladimir M. Zakharychev > N-Networks, makers of Dynamic PSP(tm) > http://www.dynamicpsp.com > Taking in account the complexity of underlying code, it seems to be *not* a straightforward action - i would rather share the Gary Myers thoughts on this subject - http://blog.sydoracle.com/2010/02/exploits-and-revoking-risks-of-revoking.html For sure only Oracle can confirm (or deny), such revoke won't break anything in provided functionality. Even Oracle would have probably difficulties to test against all usual scenarios in context of such revoke - much easier will be probably to remove vulnerability in the underlying packages. On the other side, the vulnerability is so dangerous, that i hope, Oracle's fix should follow rather sooner ( at least for those, who get lucky to login into MOS). Best regards Maxim
From: Vladimir M. Zakharychev on 7 Feb 2010 14:06 On Feb 7, 3:24 pm, Maxim Demenko <mdeme...(a)gmail.com> wrote: > On 07.02.2010 12:19, Vladimir M. Zakharychev wrote: > > > On Feb 7, 2:47 am, John Hurley<johnbhur...(a)sbcglobal.net> wrote: > >> Based on David Litchfield ... > > >>http://www.computerworld.com/s/article/9151318/Black_Hat_Zero_day_hac.... > > > He also suggests the workaround (revoking EXECUTE from PUBLIC > > on certain Java-related packages.) Actually, I'd check the privileges > > on these packages and revoke EXECUTE from everyone else, too. SYS is > > just enough. > > > Regards, > > Vladimir M. Zakharychev > > N-Networks, makers of Dynamic PSP(tm) > > http://www.dynamicpsp.com > > Taking in account the complexity of underlying code, it seems to be > *not* a straightforward action - i would rather share the Gary Myers > thoughts on this subject -http://blog.sydoracle.com/2010/02/exploits-and-revoking-risks-of-revo... > For sure only Oracle can confirm (or deny), such revoke won't break > anything in provided functionality. Even Oracle would have probably > difficulties to test against all usual scenarios in context of such > revoke - much easier will be probably to remove vulnerability in the > underlying packages. On the other side, the vulnerability is so > dangerous, that i hope, Oracle's fix should follow rather sooner ( at > least for those, who get lucky to login into MOS). > > Best regards > > Maxim Well, that's a quick and dirty workaround, not a proven remedy. You gotta decide between the real chance of your databases being compromised any time now and some remote possibility that some obscure Java-related stuff in the database will not work as expected. Finding out where the package is used is not too complex - check the dependencies, scan strings from Oracle executables for references to the package and context in which it is being called. Then decide if it's important to have it executable by anyone or by some select group of accounts where it's really needed, or only by SYS. But leaving this particular door open is a clear invitation to local and remote burglars and it better be closed one way or another. For now, the only way is to seal it completely. When Oracle releases a more gentle fix, we'll use that. Regards, Vladimir M. Zakharychev N-Networks, makers of Dynamic PSP(tm) http://www.dynamicpsp.com
From: Vladimir M. Zakharychev on 8 Feb 2010 10:52 On Feb 7, 2:47 am, John Hurley <johnbhur...(a)sbcglobal.net> wrote: > Based on David Litchfield ... > > http://www.computerworld.com/s/article/9151318/Black_Hat_Zero_day_hac... [rant] Well, the weekend's over, been 4 (if I didn't miscalculate) days since disclosure and guess what - no alert from Oracle still. Neither public at http://www.oracle.com/technology/deploy/security/alerts.htm, nor paying-customer-only at MOS, nor on their security blogs... Even a simple acknowledgment that they are aware and are working on a fix would do at this point... Do they think that if they just ignore the threat it will eventually go away? Or are they too busy rebranding Sun sites and cleaning up after CVE-2010-0073? (this one's a nice BEA heritage, full-fledged user-friendly backdoor, even no need to compose and inject shellcode to instantiate one of your own...) [/rant] Regards, Vladimir M. Zakharychev N-Networks, makers of Dynamic PSP(tm) http://www.dynamicpsp.com
|
Next
|
Last
Pages: 1 2 Prev: Physical Standby Database and v$Recover_file Query Next: Why I can not using alias in 11G |