245776 - encoded URL is not shown / invisible in mail status line

Status: RESOLVED WORKSFORME

(MailNews Core :: Backend, defect)

Description

[Markus Merz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040606
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040606

Urlencoded URLs wncoded with the following scheme are not shown in Mail/News
status line (i.e. m%E4dchen inside of variables). For encoding I use the
following table. Normally I use it to do some deep linking into a database.

# encode URL
* Tabelle (s.u.): http://ffm.junetz.de/members/reeg/DSP/node13.html
* RFC: http://www.ietf.org/rfc/rfc2396.txt

Table 8.1: urlencoded
Zeichen Code 	Zeichen	Code 	Zeichen	Code
" " 	+ 	/ 	%2F 	{ 	%7B
! 	%21 	: 	%3A 	| 	%7C
  	%22 	; 	%3B 	} 	%7D
# 	%23 	< 	%3C 	~ 	%7E
$ 	%24 	= 	%3D 	ä 	%E4
% 	%25 	> 	%3E 	ö 	%F6
& 	%26 	? 	%3F 	ü 	%FC
' 	%27 	@ 	@ 	Ä 	%C4
( 	%28 	[ 	%5B 	Ö 	%D6
) 	%29 	\ 	%5C 	Ü 	%DC
* 	* 	] 	%5D 	ß 	%DF
+ 	%2B 	^ 	%5E 	--
, 	%2C 	_ 	_ 	--
- 	- 	` 	%60 	--
. 	. 	--

Inside the browser the status line presentation is OK.

Reproducible: Always
Steps to Reproduce:
1. Testcase to create a mail with a visible and an invisible Link in
the status line:

<a
href="http://www.google.de/search?q=vespa+m%C3%A4dchen&amp;ie=UTF-8&amp;hl=de&amp;btnG=Google-Suche&amp;meta=lr%3Dlang_de">Link
with encoded German Umlaut</a>
viewable<br>
<br>
<a
href="http://www.google.de/search?q=vespa+m%E4dchen&amp;ie=UTF-8&amp;hl=de&amp;btnG=Google-Suche&amp;meta=lr%3Dlang_de">Invisible
status line Link with German Umlaut</a>

The testcase is just to show the invisible link. The invisible link is not
working because google doesn't accept this specific encoding. I just want to
show that it is possible to hide the status line which might be a serious
security issue.
2. Compose a mail and insert the testcase as HTML
3. Send to yourself
4. Move mouse over links and check status line

Actual Results:  
second link from testcase is invisible in status line

Expected Results:  
link must be visible

Comment 1

[Daniel Veditz [:dveditz]]

Confirming: in the browser both URLs show a-umlaut in the status bar, in mail
the second one has a blank status bar. How does the browser know one is a UTF8
encoding and the other is Latin-1?

The UTF8 to UTF16 converter will return a blank string when fed invalid UTF8,
and E4 by itself is invalid UTF8 (E4 is the start byte of a three byte sequence,
but the next two bytes are not in the valid x80 - xBF range). My WAG here is
that mail is feeding the statusbar text through a UTF8 to UTF16 converter.

However URLs are not UTF8 encoded, %e4 is the correct URL encoding for ä. the
other sequence would be interpreted on most servers as ä

I don't think this needs to be security sensitive, the worst you can do is blank
the entire status bar at which point the user notices something weird (plus
blanking is easily accomplished in the browser where JS is on by default). This
is in contrast to a recent exploit where an attacker could truncate the status
bar text at an abitrary point leaving a completely false and misleading impression.

Comment 2

[Daniel Veditz [:dveditz]]

cc mscott, might affect thunderbird too

Comment 3

[Markus Merz]

Again confirmed comment 0 in 1.7rc3
For QA 1.7-final I flagged it "1.7?"

Comment 4

[chris hofmann]

   in some ways the only protection for these kind of exploits is going to come
through education of users to check the status bar before clicking on
suspicous/phishy links...  

with this added to the exploit a user sees nothing... 

so the story can be "if you see a bad site, or no site, when you hover over a
link, then don't go there..."

I guess it would just be good to simpilfy the message, since it will be a hard
one for most user to understand anyway, but looks like we are out of time to get
this in 1.7...

Comment 5

[Darin Fisher]

nsITextToSubURI::unEscapeURIForUI should be used to convert a URL fragment into
a user presentable string.  the charset parameter should usually be the value of
nsIURI::originCharset.

Comment 6

[Markus Merz]

(In reply to comment #3)
> Again confirmed comment 0 in 1.7rc3
And again for 1.7.2
> For QA 1.7-final I flagged it "1.7?"
I don't flag it again. Maybe it will be solved, maybe not.

Comment 7

[Wayne Mery (:wsmwk)]

Perhaps gone?

Comment 8

[Kai Engert (:KaiE:)]

Attachment: test.eml

Doesn't reproduce with TB 68 and the attached message.
Both links are shown in the popup status line.