Mozilla browser "about:" exploit

[Siamesecat]

Here is a crash exploit which works on Mozilla browsers:
http://maas-online.nl/security/poc-mozilla-crash.html

The crash actually occurs when the browser tries to print an iframe, but I think that allowing the use of about: <string> is inadvisable when it comes from web pages.
I wrote a filter to stop it. If anybody has any suggestion for improvement, I'd welcome it. For example, can other tags be used for such a thing, and is "src=" the only way in which something like that could be set up?

Code:

Name = "About: * Exploit (Mozilla)"
Active = TRUE
Bounds = "<(a|img|image|iframe|input|script)*></(a|img|image|iframe|input|script|br)>"
Limit = 250
Match = "*src=$AV(about:\1)*"
Replace = "Exploit: about:\1"

[sidki3003]

I don't know which tags would be exploitable, but a common practice to create popups - including requested ones - is opening them as "about:blank" and then writing content to them via a script.

A fairly speedy way to cover all tags that can have a "src" attribute is:

Code:

[Patterns]
Name = "<*>: Cover "src" Tags"
Active = FALSE
Bounds = "<[efils]*>"
Limit = 4096
Match = "*\ssrc=$AV(*this*)*"
Replace = "that"

There is one tag that isn't covered this way - <applet src=...> - but adding "a" would slow things down considerably and "src" is used rarely there - Mozilla doesn't even accept it.

sidki

[Siamesecat]

Quote:A fairly speedy way to cover all tags that can have a "src" attribute is:

I was not trying to catch "src=", but "about:<whatever>" exploits. I read somewhere that many of the "about:*" codes can be exploited by malicious code, but had not thought much about it until this demo came along. Could a web page query my browser with, for instance, "about:plugins" to find out what plugins I had installed?

[sidki3003]

Siamesecat Wrote:I was not trying to catch "src=", but "about:<whatever>" exploits.&nbsp; I read somewhere that many of the "about:*" codes can be exploited by malicious code, but had not thought much about it until this demo came along.

Where? As you said, the exploit you referred to deals with printing an iframe source. "about:blank" was just an example, it works with "/nicepath/nicename.html" as well (and has been fixed in the nightly builds). See here for a "non-about" crash.

Quote:Could a web page query my browser with, for instance, "about:plugins" to find out what plugins I had installed?

Pages like "about:mozilla" work only locally, like that "I can see your hard disk!" followed by a "file:///c:/" iframe joke. The security relevant pages are disabled for remote webpages in Mozilla anyway - see here.

sidki

[Kye-U]

Here's mine:

Code:

[Patterns]
Name = "Mozilla: "About" Crash"
Active = TRUE
URL = "($TYPE(htm)|$TYPE(js)|$TYPE(vb(s|)))"
Limit = 128
Match = "(\s|)src=$AV(about:*)"
"|window.\w.\w.print\(\);"

It does the job, but it's pretty crude

[Siamesecat]

Quote:The security relevant pages are disabled for remote webpages in Mozilla anyway - see here.

That's nice to know. The about: link still shows my browser's user-agent, however (as opposed to the fake one which I usually send).

[Siamesecat]

I have revised my filter. I am not sure how to capture the iframe part of the code into it. This does stop the crash, though.

Code:

Name = "Mozilla: Prevent Print Iframe Crash"
Active = TRUE
Limit = 128
Match = "window.frames.\w.print\(\);"
Replace = "Iframe crash attempt"

[sidki3003]

Not that i want to get nasty, just for the fun of it, try again.

[Siamesecat]

OK, Sidki3003,
Here is my revision to the filter. How would I go about capturing the preceding Iframe code as well?

Code:

Name = "Mozilla: Prevent Print Iframe Crash"
Active = TRUE
Limit = 60
Match = "(window.frames.\w.print \(\);|print \(*\);)"
Replace = "Iframe crash attempt"

[sidki3003]

I don't think you can specifically target this vulnerabilty with Prox language only, unless you block all printing from within a document, which is what you're doing in your last filter. In the latter case there is no need to do anything with the preceding iframe.

I tried to intercept the print method with a script, inserting a confirm dialog. It actually works with the usual print call "window.print()" but i didn't get it to work with "window.frames.ID.print()".
There used to be some people around that where good in such things, like Paul Rupe and JarC/TEgghead, but now i don't know.

sidki

[Oddysey]

sidki;

Quote:I tried to intercept the print method with a script, inserting a confirm dialog. It actually works with the usual print call "window.print()" but i didn't get it to work with "window.frames.ID.print()".&nbsp;

According to what I can find from my references, the print method is not truly a DOM method. Rather, it is dependent on the definitions found in the DTD. You might check that resource for further clues in solving your interception problem. If that turns out to be true, I should think that Prox(o|i) could easily come to the rescue.


Oddysey

[sidki3003]

Well... here is what i used, it works the same way as the interception of "window.open()" in Scott's WindowOpen.js :

Code:

var PrxRealPrint = window.print;

function PrxPrint() {
  if (confirm("*** PROXOMITRON ALERT ***\nA script is trying to access your printer.  Allow it?")) {
    return PrxRealPrint();
  } else {
    return true;
  }
}

window.print = PrxPrint;

What needs to be changed is that not only "window.print()" but all calls to the print method get intercepted.
Feel free to fiddle with it if you like!

sidki

[sidki3003]

Siamesecat Wrote:Here is my revision to the filter. How would I go about capturing the preceding Iframe code as well? [...]

Rethinking, you could restrict blocking of "print" to only match if there was an iframe with an "id" or "name" attribute before. That would go like:

Code:

[Patterns]
Name = "Mozilla: Prevent Print iFrame Crash I"
Active = TRUE
Bounds = "<iframe*>"
Limit = 256
Match = "*\s(id|name)=$AV(?*)$SET(iFrameID=1)PrxNeverMatch"

Name = "Mozilla: Prevent Print iFrame Crash II"
Active = TRUE
Limit = 16
Match = ".(print \()\1$TST(iFrameID=1)$SET(iFrameID=)"
Replace = ".NO\1"

But that would still be much of a big gun imo...

sidki

[Oddysey]

sidki;

Hehehe - it took me about three seconds to realize that you can't be some young punk "programmer wanna-be" - not too many coders these days think of assigning a function call to a variable name!! [lol] That's a trick from way, way back, lemme tell you. Been awhile since I've seen that one, thanks for the rush of memories.

Now..... Why not set up a filter to capture the portions of a text-string between 'window' and 'print, assigning them to variables on the stack'? Modifying your function above to use these stack vars, it becomes generic in that once Proxo has expanded those variables back into string form, javascript can then properly decipher said string, and will equate it with the proper DOM object - in this case, the print method. Seems to me it outta work, but as usual, it will require more than one filter to do the job. Sigh.

Gotta go for the rest of the day, I'll check back in tomorrow, Monday. Ciao!


Oddysey

[sidki3003]

GA Oddysey, post some code.