Friday, September 12, 2008

not sure if this is good or bad...

full disclosure foo... so litchfield is a ninja and all, but i'm torn on this one...

here is a no-auth remote compromise of oracle db's from a few months back...

NGSSoftware Insight Security Research Advisory

Name: PLSQL Injection in Oracle Application Server
Systems Affected: Oracle Application Server 9.0.4.3, 10.1.2.2, 10.1.4.1
Severity: Critical
Vendor URL: http://www.oracle.com/
Author: David Litchfield [ davidl at ngssoftware.com ]
Reported: 9th October 2007
Date of Public Advisory: 15th July 2008
Advisory number: #NISR15072008
CVE: CVE-2008-2589


do you see what i saw?

it was publicly disclosed in july 08, but reported to the vendor in *oct 07*. no-auth remote compromise just hanging for the better part of a year...

i'm sorry, but if it really takes that long to dev a security patch, oracle is doing something really really wrong.

this is one of those times where (imho) dropping 0day to kick vendors in the arse is completely justified. not weaponized or anything, but get that info out there. how many other peeps found that vuln and didn't disclose? no one will ever know...

ie 8 add-ons

so ie8 supports add-ons... judging by the number of ratings, not too many people are playing around yet...

the security options are disappointing, and i'd really like more visibility into how these apps are vetted. are they ms built, or community-built? i'm too lazy to register atm ;)

here's an app from wayyyyyyyyyy back in the day... prolly my first app layer foo, for doing zebulun... lulz...

Thursday, September 4, 2008

that was quick

check this vuln out:

"denial of service vulnerability that is successfully crashing the Chrome browser with all tabs"

wait a min... they said all those tabs were separate processes to avoid futzin w/ other tabs like this. so how is this working?

An issue exists in how chrome behaves with undefined-handlers in chrome.dll version 0.2.149.27. A crash can result without user interaction. When a user is made to visit a malicious link, which has an undefined handler followed by a ’special’ character, the chrome crashes with a Google Chrome message window “Whoa! Google Chrome has crashed. Restart now?”.


think it was a fuzz?

i haven't dug around the nix source yet, but i bet the protocol handler is part of the chrome process, and receives data passed up by all of the tab processes.

those critical vulns that affect the entire browser space are still there... prolly time will tell if there are less, or if they're harder to get too, or easier to fix. ;)

Wednesday, September 3, 2008

google chrome security thoughts

some peeps say nay and others say mb...

looks like pdp is running w/ it as a model changing the way we use computers...?? he doesn't say so, but it sure sounds similar...

there have been a number of vulns (carpet bombing, etc) reported so far, but i'm not too worried about those. this is beta software, so we have to expect there will be some oversights which can be exploited. so, based on what we know today, how do we see the design changes which will be present in the final release impacting security?


[process isolation]



process isolation may defeat some client side attacks... are cookies isolated to their tabs? if so, browsing separate domains via tabs may offer some protection from cookie stealing and CSRF.

this is kinda out there, but since processes are isolated, watchdogs on memory and proc usage (mb io?) may be able to identify 0day-ish attacks which are consuming resources...? that's a long shot tho...


[incognito]



incognito mode seems nice on many levels. i've heard jokes about how it's just a pr0n-mode, but there are many times i browse around online where i don't want to allow any web site to write anything to disk (ie: reading headlines on digg). i don't expect anything hostile to happen, but there are attacks (ie: malicious ads/apps via 3rd party content) which could be bumped into. why not use incognito for daily-browsing? might it be a reasonable alternative to running no-script, ad-block, cookie-safe, and flash-block?

i do question whether or not this is read-only, or just a more restricted jail. it seems like temporary file writes will still be required, but i'm not quite sure...


[attack vectors]

so what attacks look possible under this design?



so if users drag pop-ups out, and they get promoted to their own windows, how does that impact sec? does all retained information (cookies, history, etc) propogate to the new process for the pop'd out tab?



sandboxing seems very very good... lots of badness (malicious jscript stealing creds, keylogging, etc) is mitigated in this model. but can it be attacked? if each process is isolated, can an escalation attack upward against the master chrome process succeed in breaking the security model? that brings the question of how much chrome security depends on the isolation model being maintained (ie: how bad are things if isolation is gone; are we just back to where we were w/ browsers pre-chrome? or is it worse b/c we assumed we'd be isolated and so didn't take other sec steps)



the idea of tracking what a user has actually requested is pretty nifty. reminds me of packet-filters (old browsers) vs stateful firewalls (chrome). the comic here points out that plugins don't conform to this model, so those may be a weak-point. another issue will be whether or not a process can create a false user request. can a malicious pwnt tab process mimic some type of user request, either in the local tab or in another tab process.



sandboxing plugins reduces risk, but they can now attack upward as well? will a flaw in a plug-in feature (ie: quick-time, flash) potentially open the chrome process to attack?

another interesting tidbit in the diagram is that the chrome process links pages to plugins. can this be abused somehow? can plugins associate themselves w/ alternate pages? what makes a process eligible to be linked to a plugin process? etc etc etc...

that's all i've got for now. chrome seems to offer some nifty and refreshing looks at browser design.