The icon ** ISN'T ** designed to contain executable code, per se.
What's happening is that griefers and other miscreants have identified a flaw in the shortcut parsing mechanism that can be exploited by filling parameter fields within the shortcut with unexpected data.
These parameter fields are descriptors that are used to tell Windows what folder/file the shortcut points to, what application the target's MIME type is registered to, what image/bitmap to use to draw the shortcut's icon, things like that.
When the shortcut parser encounters this malformed data, instead of failing gracefully, the parser fails in such a way that causes the malformed data to be executed as machine code. This parameter-data-turned-machine-code can be used to do all sorts of nasty and/or unexpected things, depending on the privileges the code inherits from the parser, and/or the code's ability to break through the other layers of Windows' security subsystem.
This kind of attack can theoretically work on any OS with a modern, shortcut-and-icon-based GUI (including Linux and Mac OS X), ** IF ** the shortcut parser isn't up to snuff (in other words, is suffering from the same style of bug).
All you need to do is fill a *.desktop file (for a Linux desktop environment like GNOME or KDE) or resource fork (Mac OS X) with lots of specially-crafted extraneous data, and ** IF ** the GUI's shortcut / icon / *.desktop file / resource fork parser breaks in the right way, you ** MAY ** be able to exploit the situation to run arbitrary code.
Note that I am NOT saying that Linux or Mac OS X suffers from the same kind of hole. A lot of things need to fall into place in order to successfully exploit a weakness in any operating system component. I am speaking hypothetically, hence the prodigious use of the word ** IF **. No operating system is bullet-proof.