867907 - Ignore BASE tag in BODY (Webmail hijack - old Horde IMP UI becomes useless)

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Dr B W Darvell]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130409194949

Steps to reproduce:

Opened a message in webmail.


Actual results:

All links (delete, reply, forward, message source, up, down ...) hijacked to point to a Russian mail server: e.mail.ru

This happens in FF, Chrome and Comodo, and appears to be a simple code insertion or search and replace.   

The only way out was close the tab - logout or anything normal or graceful was impossible. 

There were no AV or firewall warnings; a scan produced nothing.




Expected results:

Normal functions and navigation.

This may just be a misguided attempt at being helpful, but my concern is that it would lead to a 'drive-by' attack as one does not ordinarily check every link for the intended target.  So is this capable of being handled?  Probably not, if the injection occurs at source.  I hope I am wrong, but I find it hard to imagine how such a thing would be detected.  But it is conceivable that other text could be captured in the process.

Comment 1

[Dr B W Darvell]

Attachment: Russian email hijack (FF example)

Comment 2

[Dr B W Darvell]

Attachment: Russian email hijack (Comodo example)

Comment 3

[Dr B W Darvell]

Attachment: Russian email hijack (Chrome example)

Comment 4

[Dr B W Darvell]

I should have said that my correspondent is genuine, that she was using her Russian email account: @mail.ru, and that a check of her machine produced no sign of malicious entities.

Comment 5

[[:Aleksej]]

Apparently the server is running a version of Horde IMP from 2001!  And the problem is probably server-side only.

Comment 6

[Dr B W Darvell]

Thanks.  I have informed the people there and they are checking.

Meanwhile, I have downloaded the same original message into Eudora (7.1) using both IMAP and POP.  One section is modified.  This is from a clean message (another sender):

<a href="http://www.phplist.com"><img src="powerphplist.png" 

and this is changed to:

<a href="http://www.phplist.com" target="_blank"><img src="https://img.mail.ru/mail/ru/images/dumb.gif" badrealimg="powerphplist.png" 

in both, with other links being unaffected.  No other effects noticed.  

So, something is happening it seems in the message that is sent, although this is then made worse by the webmail system at HKU.

Comment 7

[[:Aleksej]]

http://otvety.google.ru/otvety/thread?tid=33015cca65cb7101 says it's what mail.ru does to img src without "http://".  Assuming the message went through mail.ru.

Comment 8

[Dr B W Darvell]

This report from HK:

++++++++++++++
We make some test about the issue that you mentioned. It happened on the HKUCC webmail while using Firefox, Chrome, but IE is not affected.

Seems the IMP 3 is doesn't  handle HTML mail very well while the mail contains <base target="_self" href="https://e.mail.ru/cgi-bin/"> which cause links in the web page became invalid.

In fact we have a plan to upgrade the HKUCC webmail to a newer version. We also performed testing for this issue on the newer version IMP, it is not affected. However, we still need more time to solve some technique difficulty for the upgrade.

In order to fix this problem ASAP, we are thinking of applying a quick fix for in the current IMP webmail to bypass the <base> element in the mail body. We need some more time to test it before we deploy to the production.

For the time being, you may use IE to access the webmail to prevent the issue.
++++++++++++

So, not a browser problem as such, but odd that IE is unaffected (no mention of version, but IE8 is OK).  What is the difference, then, in the way that FF interacts?

Thanks.

Comment 9

[Hallvord R. M. Steen [:hallvors]]

I'm aware of other security issues in old Horde installs.. 

Now, BASE should of course only be used inside HEAD per the HTML standard. It's very interesting if IE actually gets away with enforcing that constraint - in that case, we might also remain web-compatible even if we ignore BASE inside the document itself, thereby rescuing pages like this old Horde from their failure to properly sanitize away the BASE tag..

IMO we should fix this in core, because IE's behaviour seems cleaner and safer. We might of course come across pages that break from this change, but those would be pages that were broken in IE already, so it should be very rare.

Comment 10

[Hallvord R. M. Steen [:hallvors]]

Attachment: Test case

Comment 11

[Dr B W Darvell]

Thanks for the comments and clarification - although not in my domain of expertise, unfortunately, but interesting that it is worth pursuing for FF.  (The test case fails in my FF 22, passes in IE8.) In the meantime, the "quick fix" was applied by my CC and seems to have been effective.  I have no idea what they did.

Is there a link to the "other security issues" so that I can advise my CC?

Thanks.

Comment 12

[Hallvord R. M. Steen [:hallvors]]

Anne, any standards input for this issue?

Comment 13

[Anne (:annevk)]

Yeah, this was considered on the WHATWG/HTML lists and rejected. I think we should mark this INVALID.

Comment 14

[Hallvord R. M. Steen [:hallvors]]

I'm trying to find the conclusive decision..

http://lists.w3.org/Archives/Public/public-whatwg-archive/2007Feb/0179.html ?
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/030040.html ?
http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0022.html ?

Comment 15

[Anne (:annevk)]

The specification contains that :-) Until implementations diverge from it anyway.

Comment 16

[Hallvord R. M. Steen [:hallvors]]

Yes, the spec changed here: http://html5.org/r/5711 but I haven't yet found the discussion that caused this change. Feedback like this from bz http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/030040.html indicates that the change actually *caused* problems when implemented, and as mentioned IE gets away with doing something that seems both cleaner and safer. 

(Now, further e-mail in the thread started by bz explains some compat issue other browsers ran into but IE escaped for other reasons, and this caused a problem on united.com. I can't find this issue in bugzilla, so it's hard to start figuring out if it's still a problem).

Comment 17

[Hallvord R. M. Steen [:hallvors]]

(and in a quick check I found no pages on united.com that contained faux namespaces in head like the <foo:bar/> parsing issue described in the thread.)

Comment 18

[Anne (:annevk)]

So I would have expected that issue to be re-raised if it was still a problem. More investigation is always good though. Maybe we should add a test to the HTML testsuite.

Comment 19

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

clearing sec-review flag here for now as there is no action for security

Comment 20

[Dr B W Darvell]

"as there is no action for security"
Really?  As a mere user, this strikes me as odd since this mechanism could redirect anywhere, and in particular to drive-by sites: no knowing what could be launched.  It was a bit disturbing to find a Russian website linked everywhere ...

Comment 21

[Henri Sivonen (:hsivonen)]

(In reply to Hallvord R. M. Steen from comment #16)
> Yes, the spec changed here: http://html5.org/r/5711 but I haven't yet found
> the discussion that caused this change.

See http://lists.w3.org/Archives/Public/public-html/2010Dec/0051.html

(In reply to Dr B W Darvell from comment #20)
> "as there is no action for security"
> Really?  As a mere user, this strikes me as odd since this mechanism could
> redirect anywhere, and in particular to drive-by sites: no knowing what
> could be launched.  It was a bit disturbing to find a Russian website linked
> everywhere ...

Seriously, it's totally reckless to use an old version of IMP/Horde. If it allows a base tag from an email to reach the browser, it probably allows other stuff as well, in which case you have much bigger problems. The right security response is to upgrade the webmail app.

Comment 22

[Dr B W Darvell]

I think we are at cross-purposes.  I accept the point about the old webmail, but if FF is affected while IE is not it seemed to me that the remark was inconsistent, shall we say.

Comment 23

[Hallvord R. M. Steen [:hallvors]]

Henri, thanks for pointing our the right discussion. So this decision was based on bug 593807 and bug 592880, both serious compat issues.

So, compat vs security is never an easy dilemma to resolve. In principle filtering untrusted code is really very much the responsibility of a site that wants untrusted code rendered. We can not generally double-guess what the site is doing and drop random tags because we think it might be including untrusted content and not filter it well enough.

The counter-arguments are of course that the other two sites are also doing it wrong per the old spec, and if some browsers (IE) follow that spec and others can be convinced to join them we can tighten up implementations and get the sites fixed. In this case, that would have a minor security benefit as it would protect users of old Horde deployments from certain abuse, and possibly save other sites with imperfect filtering. However, this rarely works on the web: "liberal" implementations of a spec are contagious, "strict" implementations are not - because tolerating site errors is very much a competitive advantage for a browser vendor. (Also, regarding <base> parsing it turns out IE's strictness has some "loopholes" that means certain faulty sites got away with it - and if we were to move to a stricter model only to add complex rules for when to be liberal anyway we'd end up in some real insanity.)

Closing as invalid. I hope your old Horde is or will be upgraded, Dr. Darvell.

Comment 24

[Dr B W Darvell]

Understood, thanks.  I, too, hope they will upgrade.
Anyway, thanks to all for input and discussion.