Op Tue, 24 Apr 2007 11:22:59 +0100, schreef Roy Schestowitz:
> Program Names govern admin rights in Vista
>
> ,----[ Quote ]
> | "This is a little bit silly: just name the installer something
> | else, and Vista lets it through," Chess said. He added that
> | although the feature is imperfect and inconvenient, it's
> | "better than nothing".
> `----
>
> http://www.theregister.co.uk/2007/04/23/vista_program_naming_oddness/
>
> Workarounds, hacks, and some loose 'security' bolted in on top. How about
> rebuilding the operating system? This is just as lame as managing
> execution/handling privileges based on file extensions (filenames).
Not to mention the horrible mistake of keeping those extensions hidden
from users by default - something which hasn't changed in Vista. The
effect is that deceiving both Windows and its users with respect to the
nature of any particular file is completely trivial, because renaming the
file and/or its extension is completely trivial.
In *nix, things are far better: the system determines the nature of a file
by inspecting its headers, which are somewhat less easy to change, while
the extension serves the primary purpose of informing the user. An example:
$ ls *.rpm
testdisk-6.6-1.i386.rpm
$ file testdisk-6.6-1.i386.rpm
testdisk-6.6-1.i386.rpm: RPM v3 bin i386 testdisk-6.6-1
$ mv testdisk-6.6-1.i386.rpm justaname.txt
$ file justaname.txt
justaname.txt: RPM v3 bin i386 testdisk-6.6-1
Nope, Linux isn't fooled by the complete change in name. And although
Linux users can be fooled just as easily as in Windows, there are no
extensions (e.g. exe pif com bat scr) which cause files to be executed
automatically when clicked - and there's no mechanism which hides an
(for the user) essential part of a file name, enabling attacks such as
NakedGirl.jpg.scr, which still arrive in mailbox on an almost daily basis.
Instead, the x bit must be set first (and the /home partition must not be
mounted as noexec, but this latter measure isn't very widespread AFAICS).
Otherwise, you're 99.9% safe from bad things executing surreptitiously or
by accident (the "oops" factor).
What bothers me the most about this latest display of Microsoft's
incompetence, is that someone over there (or more likely several someones)
thought about this, and decided that it would be a good idea.
The result is that one of the most basic, essential actions/decisions in
an operating system ("to execute or not to execute") now depends on the
/appearance/ of a file, an arbitrary categorization of what might
constitute a threat, instead of what a file actually tries to /do/ (as in:
write in the Registry or system directories) - and this applied to a
completely unpredictable outside world.
This kind of botch jobs and stupid design decisions contribute greatly
to the all-too-familiar quirks and unexpected behaviour in Microsoft
products. And the more of these ad-hoc solutions are in place, the less
reliable, predictable and maintainable a system becomes. Just think of
what could happen if this list of "suspect" file names is extended one
day, e.g. in the course of a routine system update ... something which
worked just fine yesterday may all of a sudden fail to work properly.
And at first, no-one will understand why. And even if it's clear why it
happened, it's not easy to fix - especially in Windows, where the file
name is the most important characteristic of an application, as far as the
OS and perhaps supporting applications are concerned.
Other examples of course are the old Outlook "begin" nonsense, and this
Zune "protection measure", where a DRM system was in place to prevent
unauthorized sharing of music files - by just checking the file name
extension. How stupid do they think the rest of the world is? Just as
stupid as themselves, I gather.
As long as Microsoft keeps coming up with this sort of "defective by
design" "solutions", their products just can't be considered fit for use.
Richard Rasker
--
Linetec Translation and Technology Services
http://www.linetec.nl/
|
|
