The Only Secure IM Client
The architecture of Instant Messaging has for several years been a matter of
divergence between theory and practice. In theory, IM should be as distributed
just like email — every domain managing its own users. In practice,
though…how is email doing with its massively distributed infrastructure?
Not so well, with an astonishing number of users ending up at centralized
providers that not only just mimic the choose-your-megacorp model used by IM, but are actually run by the same companies.
But what are the security implications of such centralization? Couple years
back, AOL had an exploit against their IM client get out. Tens of millions of
users were vulnerable…but only a few thousand actually got infected.
Say what you will about centralization — the filters worked. 10M unpatched endpoints stayed safe.
Filtering instead of patching is an interesting question. It’s worth pointing out that, while AOL wasn’t going to let the malicious payload pass, anyone with local access to a user’s unprotected packet stream could inject the centrally filtered payload. And filters have a nasty habit of not encapsulating sufficient logic regarding the nature of all possible exploits — in other words, a slight change in the attack and the filter fails while the broken code remains. But yet the perfect is often the enemy of the good, let us not forget that what would have been a product killing exploit anywhere else fell by the wayside because of an effective centralized filter.
We have to discuss Microsoft for a moment. They actually have people who
believe quite strongly in filtering as a first level of defense. I ended up
meeting one of the researchers from their Shield project at MSR. Smart lady, interesting ideas on the future of security. Hopefully I’ll get my hands on the Shield code — if there’s one thing that they do right at MSR, it’s make cool code available for download. (And I bet you thought I couldn’t turn another entry into, oh look cool toys.) Now, MSN has been suffering from a serious number of very nasty worms — including those that (um, finally) actively defend themselves against disinfection techniques. The worms were using the MSN IM client’s ability to transfer files. They needed to do something.
What they did was…astonishing. My GF was annoyed to find her friend couldn’t send her an MP3 file. For a while we thought this was a sop to RIAA. A moment of searching showed there was quite a bit more that was being blocked.
The blocked file extensions are: .exe; .bat; .com; .cmd; .reg;
.vbs; .inf; .msi; .htm; .html; .swf; .js; .mp3; .mp2; .ape;
.apl; .flac;.shn; .mpc; .mp+; .wma; .ogg; .mp4; .aac; .voc;
.mid; .mac; .cda; .kar; .midi; .rar; .zip; .wav; .jpg; .gif;
.png; .bmp; .jpeg; .doc; .xls; .pls; .pub; .dat; .html; .htm;
.avi; .mpg; .mpeg; .nfo; .txt; .torrent; .diz; .ppt; .m3u;
.sfv; .tar; .htt; .mht; .asp; .aspx; .tiff; .rtf; .ini; .cab;
.ico; .icl; .ip; .iptheme; .msstyles; .theme; .dll; .psd;
.vbs; .swf; .php; .xaml; .iso; .bin; .cue; .xml; .par; .par2;
.ace; .arj; .lzh; .7z; .gz; .bz; .uue; .bz2; .jar; .z; .ade; .adn;
.adp; .aia; .img; .date; .aip; .ait; .amf; .ani; .aob; .asf; .csv;
.fla; .pxr; .wmv; .nrg; .mov; .sav; .xhtml; .php5; .pxr; .m4a; .qxr;
.h; .cpp; .pdd; .rle; .dib; .eps; .jpe; .pcx; .pdp; .raw; .pct; .pict;
.sct; .tga; .vda; .icd; .vst; .tif; .tpl; .log; .prx; .cdf; .nls; .ax;
.msc; .cpl.
A small game — find an extension that isn’t blocked. Took me about eight tries. We’ve said for years that the only secure system isn’t plugged into anything. It’s usually followed by, “but obviously that’s not an option”…
Dan Kaminsky's Blog 