TYPO3 Core

The solution is easy: TYPO3_SITE_URL is not needed, so it can be removed from the favicon URL.

This will lead to an entry like this, right?
<link rel="shortcut icon" href="/fileadmin/.../favicon.ico" />

I think IE6 will not display the favicon (in the bookmarks) if the domain is missing (can't test atm).

Not exactly. The filepath is not prepended by a slash.

But now I understand why the hostname was added to that path. Still, adding TYPO3_SITE_URL should be avoided because of the problems described above.
I think we should try to solve the problem if it's easy to do. Otherwise we should probably just forget about IE6 (hey, it's just the favicon, everything else works fine like before).

So I propose the following:
a) Keep it like proposed in my patch (remove TYPO3_SITE_URL)
b) Use $TSFE->baseUrl if it is set, otherwise fall back to a)

I would go for b) and add a note to it, so we remember to remove the baseUrl again if IE6 support is ever being dropped.

What do you think?

How exactly do you force TYPO3 to point to http://www-evil-domain.com/? Doesn't it always point to the correct icon file inside the proper domain?

/etc/hosts is a client file. So if you modify it on your computer, only you will be affected. You will not be able to send anyone else to the wrong IP address with /etc/hosts.

Do I minuderstand something in this issue? I do no see any threat.

How to I reproduce it on multiple computers?

If I understand correctly:
- You hack your local client to point www.some-malicious-domain.com to the IP of the target domain.
- You access www.some-malicious-domain.com
- If the target server side system has a catchall domain on this IP (reacts on all given domain names) and without a redirect to a valid domain, then TYPO3_SITE_URL will be www.some-malicious-domain.com.
- The favicon link will then point to the malicious domain, the entry will be cached and sent to other users afterwards.
- The browser of some other user will then GET the malicious domain favicon, which is a problem because a) if the browser has some security hole handling the favicon icon, and b) the attacker could gain informations on how often the targetted site is accessed.

Michael, solution to use baseURL and fallback to no domain name sounds fine.

I'm fine with the change Michael suggests, but I do not consider this an important issue.
Like Christan wrote the server side system (webserver) must be configured to accept all domains with a given IP which is a misconfiguration in my eyes,

I'm also in favour of solution (b) Stucki mentioned above.

I think we can safely ignore IE6 for an issue as small as a favicon.

@Christian: Yes you understood correctly.

So as it seems that we agree it's not a big issue, I propose to do the following:
I will keep this issue marked private and submit a new one instead. Reason: Nobody should see how this can be misused.

I nobody objects I'm gonna do this tomorrow, and submit the RFC for the new bug report to the core list...

Michael, could you please add the other ticket as a relation to this one (and close this one if the other one has been closed)? Thanks!

Checked 4.7 and also master (currently 6.2). Both still have:
$favIcon = $GLOBALS['TSFE']->tmpl->getFileName($GLOBALS['TSFE']->pSetup['shortcutIcon']);
// ...
$pageRenderer->setFavIcon(t3lib_div::getIndpEnv('TYPO3_SITE_URL') . $favIcon);