5 ms·
The idea to do something like that is just plain... ugly. It's almost like guessing MIME type based on the file content (hint: IE). I wonder how long it will ta
by amenod 13y ago
The idea to do something like that is just plain... ugly. It's almost like guessing MIME type based on the file content (hint: IE). I wonder how long it will take until someone finds a security exploit of this "feature"?
- TeMPOraL 13y ago> It's almost like guessing MIME type based on the file content (hint: IE). Hint: Linux? It does something similar pretty much on the OS level.
- elehack 13y agoThat's on your file system. The HTTP protocol specifies that, if the server says a document is 'text/plain', the client must not attempt to second-guess it based on content. IE second-guesses it based on content, so you cannot serve up something that looks like HTML as text/plain to get it to display. Substantially worse, IMO. That said, it'd be better to actually save content types in extended attributes or something. And make all applications magically save and respect these attributes.
- annnnd 13y agoActually MS broke HTTP protocol on that one and it lead to some very interesting exploits. Malicious user could upload a GIF to some site which allowed image uploads. Image would appear normal to a casual observer, except that it was specially crafted so that IE thought it was actually a JavaScript file (because it guessed the file type on its contents and didn't obey server-side set MIME types) and executed it -> XSS. I don't think Linux does anything remotely like this. It does allow you to use "file" utility to guess the contents of the file, but it doesn't act on it.
- Theriac25 13y agoWhat the fuck are you talking about?
- Too 13y ago#! shebang i assume?
- derleth 13y agoThis is a lot more involved than magic numbers, and magic numbers are configurable.
- SEMW 13y ago> I wonder how long it will take until someone finds a security exploit of this "feature" I'm not sure what exactly crafting a 16-bit installer file to exploit some bug in the bundled installshield to get it to execute code of your choosing (when the user tries to run your installer) would achieve. You've got the user to run an installer that you've made. They've just double-clicked on your program. Forget crafting dodgy installer data files, you can run whatever code you like just by... running it. Moreover, given the user is trying to install your program, they'll be happy to elevate its privileges, too (through UAC). So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you? (And if the user doesn't think your program's an installer, they're not going to be any less confused by the appcompat installshield's UAC prompt than if your program just tries to elevate by UAC by itself. It's not like the bundled one is setuid root (or the windows equivalent)). See also: http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...
- doug11235 13y ago> So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you? In the days of Antivirus products and executable whitelists, the "elevation of privilege" may be getting arbitrary execution as any user. Of course trustedinstaller.exe or whatever that has a valid Microsoft signature can run, why shouldn't it? No need to ship that file back home either for further analysis (as AV products like to do with unknown files), its a standard OS thing. Therefore my rootkit isn't burned either.