C
cquirke (MVP Windows shell/user)
On Sun, 19 Jun 2005 08:01:03 -0700, xpmark
**** Contains *BONUS* drag-and-drop quiz! ****
Less sware would be needed, perhaps. Actually, I'm more inclined to
wish MS would provide better tools to reclaim ownership from malware,
given that it's so easy for malware to own the system.
There are several ways malware can run and own the system:
- user deliberately infects the system
- user accidentally initiates behavior that infects the system
- software accidentally initiates behavior that infects the system
That's it; that's the only way it happens. Now let's look at
"accidentally". The core of this is that the expected risk is lower
than the actual risk - and *that* is what malware is all about.
Now what goes into this failure to match expected vs. actual risk?
Firstly, the software may act without any initiation from the user.
In such cases, the software vendor is fully responsable, and the user
bears no blame at all - unless the user deliberately increased the
automatic risk level, which is the same decision in a different place.
Secondly, the software may misrepresent the risk level to the user,
e.g. making no distinction between viewing a data file and running a
code file, by hiding the difference between data and code (e.g. hiding
extensions while allowing code to wave data-like icons at the user,
and using the meaningless generic term "open" for both actions).
Thirdly, the software may display one level of risk to the user, but
then take a significantly greater risk. For example, an RTF file
should contain no macros and thus be safe, but having displayed the
file as a "safe" RTF, Word will run Word macros in it, even though
they should not be there. Or the code may be designed to handle the
data safely, but be exploitable via code defect, as was the case with
JPEG files handled by GDIPlus.dll
Here's a list of screwups; sort 'em into Firstly, Secondly and Thirdly
- raw .exe code within a .pif file
- not showing any file type information at all (*NIX)
- always-hidden .pif extension
- allowing web sites to generate fake "system" dialog boxes
- allowing web dialogs to OK an action when cancel or [x] is clicked
- HTML fake URL text over a different actual URL
- passing BHOs through firewall egress as part of IE
- waving RPC and LSASS at the Internet
- hidden admin shares that expose the entire HD
- running an Autorun.inf dropped into a HD root
- booting 1.44M or CD before HD by default
- Sun Java "updates" that leave old versions available for use
- generically "opening" executable attachments in HTML
- running scripts within email "message text"
- running scripts from a folder's "Web View" .htt
- automatically binding File and Print Sharing to TCP/IP on DUN
- automatically binding File and Print Sharing to TCP/IP on WiFi
- hiding attachments within mailboxes, where av can't scan them
- allowing code within ADS, but providing no UI to see ADS
- running startup items and screensaver within "Safe" mode
- exploitable indexing service touching files in the background
- exploitable icon extraction code that runs whenever icon's shown
- running code within .CPL files when listing Control Panel
- allowing scripts within "text" cookies
- Cmd.exe running raw code irrespective of file name extension
Ah well, that's a long enough list for now - half of that stuff is "by
design" and not acknowledged as problems to patch by the relevant
vendors. Which means your risk management has to go beyond patching,
and seating a firewall in front and an av as goalie to catch the flak.
Bonus exercise; apply the above list to this list of the basic things
a user needs to understand, and thus know about content:
+ whether it's from the local PC, the network, or the Internet
+ whether it's data or code
+ whether an action will "run" or "view" something
+ whether something is shared or not shared
I do not believe that complex software can be free of defects. I do
believe that complex software can be designed to take fewer risks,
with the possibility of defects in mind. And I do believe we do a
VERY poor job of displaying the level of risk to the user in a way
that is easy to understand, and of ensuring software acts purely
within the level of risk displayed.
This isn't rocket science that needs computing to be re-invented in
terms of Trustworthy Computing hardware, hard and verifiable
identities, or even devolving security down to the file system. It's
not even security as such; it's safety.
It's meaningless to know that Mary did X, if a lack of safety means
that while Mary really mean to do X, what she actually did was Z.
We also lack "depth". If we accept that "if a bad guy can run code,
then it's not your system anymore", and then proceed to allow every
web site, banner ad, unsolicited email "message" and "document" file
to run code, then we should accept the need for a platform and tools
to regain ownership of the PC from whoever we threw it away to.
**** Contains *BONUS* drag-and-drop quiz! ****
Paying for anti-virus software is like contributing to a conspiracy. If
Microsoft would make a decent operating system, all this security software
would not be needed.
Less sware would be needed, perhaps. Actually, I'm more inclined to
wish MS would provide better tools to reclaim ownership from malware,
given that it's so easy for malware to own the system.
There are several ways malware can run and own the system:
- user deliberately infects the system
- user accidentally initiates behavior that infects the system
- software accidentally initiates behavior that infects the system
That's it; that's the only way it happens. Now let's look at
"accidentally". The core of this is that the expected risk is lower
than the actual risk - and *that* is what malware is all about.
Now what goes into this failure to match expected vs. actual risk?
Firstly, the software may act without any initiation from the user.
In such cases, the software vendor is fully responsable, and the user
bears no blame at all - unless the user deliberately increased the
automatic risk level, which is the same decision in a different place.
Secondly, the software may misrepresent the risk level to the user,
e.g. making no distinction between viewing a data file and running a
code file, by hiding the difference between data and code (e.g. hiding
extensions while allowing code to wave data-like icons at the user,
and using the meaningless generic term "open" for both actions).
Thirdly, the software may display one level of risk to the user, but
then take a significantly greater risk. For example, an RTF file
should contain no macros and thus be safe, but having displayed the
file as a "safe" RTF, Word will run Word macros in it, even though
they should not be there. Or the code may be designed to handle the
data safely, but be exploitable via code defect, as was the case with
JPEG files handled by GDIPlus.dll
Here's a list of screwups; sort 'em into Firstly, Secondly and Thirdly
- raw .exe code within a .pif file
- not showing any file type information at all (*NIX)
- always-hidden .pif extension
- allowing web sites to generate fake "system" dialog boxes
- allowing web dialogs to OK an action when cancel or [x] is clicked
- HTML fake URL text over a different actual URL
- passing BHOs through firewall egress as part of IE
- waving RPC and LSASS at the Internet
- hidden admin shares that expose the entire HD
- running an Autorun.inf dropped into a HD root
- booting 1.44M or CD before HD by default
- Sun Java "updates" that leave old versions available for use
- generically "opening" executable attachments in HTML
- running scripts within email "message text"
- running scripts from a folder's "Web View" .htt
- automatically binding File and Print Sharing to TCP/IP on DUN
- automatically binding File and Print Sharing to TCP/IP on WiFi
- hiding attachments within mailboxes, where av can't scan them
- allowing code within ADS, but providing no UI to see ADS
- running startup items and screensaver within "Safe" mode
- exploitable indexing service touching files in the background
- exploitable icon extraction code that runs whenever icon's shown
- running code within .CPL files when listing Control Panel
- allowing scripts within "text" cookies
- Cmd.exe running raw code irrespective of file name extension
Ah well, that's a long enough list for now - half of that stuff is "by
design" and not acknowledged as problems to patch by the relevant
vendors. Which means your risk management has to go beyond patching,
and seating a firewall in front and an av as goalie to catch the flak.
Bonus exercise; apply the above list to this list of the basic things
a user needs to understand, and thus know about content:
+ whether it's from the local PC, the network, or the Internet
+ whether it's data or code
+ whether an action will "run" or "view" something
+ whether something is shared or not shared
I do not believe that complex software can be free of defects. I do
believe that complex software can be designed to take fewer risks,
with the possibility of defects in mind. And I do believe we do a
VERY poor job of displaying the level of risk to the user in a way
that is easy to understand, and of ensuring software acts purely
within the level of risk displayed.
This isn't rocket science that needs computing to be re-invented in
terms of Trustworthy Computing hardware, hard and verifiable
identities, or even devolving security down to the file system. It's
not even security as such; it's safety.
It's meaningless to know that Mary did X, if a lack of safety means
that while Mary really mean to do X, what she actually did was Z.
We also lack "depth". If we accept that "if a bad guy can run code,
then it's not your system anymore", and then proceed to allow every
web site, banner ad, unsolicited email "message" and "document" file
to run code, then we should accept the need for a platform and tools
to regain ownership of the PC from whoever we threw it away to.
Drugs are usually safe. Inject? (Y/n)------------ ----- --- -- - - - -