Hello MaXxX, On Tue, 13 Jul 2004, at 00:56:18 [GMT +0200] (which was 6:56:18 PM in NY, USA) MaXxX wrote:
>> Fetch alone can't trigger anything, to my knowledge. > Oh yes, it can. It's an HTTP request, so it can easily be: > 1. traced - after all, the owner's IP is verified > 1.1. traced for specific user's IP - spam sent with unique ID > numbers, acting as involuntary "reading receipt" > 2. counted - again, for benchmarking how many users have TB installed Agreed but for all the above but none of these trigger a thing locally. And still, this can only occur from servers I designate. That means *me* specifying what happens on *my* machine...not yours, and not those of any other TB users. Perhaps these are good arguments for administrative control but not for the tossing of the auto-download option. > 3. overflowed - with chunked content-type, and evil chunk lengths, > some fetchers might get confused This is an interesting one. I'm interested to hear Leif, Marck, and 9Val on this. Without understanding exactly how TB handles the transaction, I'd still say you're thinking more in terms of something like IE which could allow ActiveX type script to execute. With TB, I'm thinking that all the fetch command does is retrieve the image and mark its notation. It alone probably doesn't have any part in triggering the display. Also, I was once sent a message with a header that was too long. TB refused to receive it. I can't think of any reason why one would believe that RitLabs' HTTP handling would be any different. I concede that this is entirely faith based. > Not to mention that this makes TB! a "wormhole". Suppose that a user > has his machine firewalled. They stupidly click a download link on > some webpage, and install some trojan. The trojan can hardly try to > connect to the outside world, as it would be detected by the firewall. > But it can safely wait for TB to download new data, with new > instructions, new payload, perhaps... That's not a TB vulnerability. That's a browser vulnerability. Please, someone count the number of steps a user must take to have rogue image auto downloading become even a slight danger to themselves. Don't forget that they must first start by enabling rogue display and auto-download which are disabled by default and then allow another application's vulnerability to be exploited. This last part is key because it is at that point that *anything* on the system can be compromised...rogues or no rogues. Security, IMO, is not necessarily protecting every user from themselves. It's more the provision of tools and defaults. For example, just because I can go to the Address Book, click on Joe Blow, click on personal, and click "Go" to launch Joe's possibly compromised Web site that I would have to enter does not mean we should get rid of the ADB or the Personal Web Homepage entry. -- Best regards, James [EMAIL PROTECTED] http://www.stamp-co.com The Bat! v.2.12 RC/3 Windows XP build 2600 AMD Athlon 1Ghz 1.0 Gb RAM
pgptKnLbxfzxd.pgp
Description: PGP signature
________________________________________________________ Current beta is v2.12 RC/4 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
