• Home
• Reviews
• News
• Downloads
• CNET TV

About me

My posting summary

1 to 2 of 2

My comments

• RE:: near flat InfoSec EEG
   
  And the blame resides equally with "vendors" as with "customers."
  
  Too many vendors "blow smoke" (aka over sell a product's true capabilities, largely by selling "features" as if they were a vetted architecture) and "flash mirrors" (withholding vital information, some times in the face of direct questions) about what their latest-and-greatest does not manage to accomplish. (For the vendors of "bad" products, disclosing the truth would be a matter of "confession.")
  
  Both failures are not to be excused.
  
  Customers have to be faulted for being predisposed to seek out SnakeOil/SilverBullet/EasyButton "solutions" to complicated InfoSec problems.
  
  The brain *is* *barely* functioning.
  
  People are not thinking strategically and pro-actively. They are mostly reacting and they are well conditioned to spending out their quarterly budgets according to a deadline, not according to a well defined mission.
  
  That's why so much garbage gets sold and bought in the name of Security.
  
  Security is hard and the hardest parts are very easy to get wrong.
  
  Concrete facts have to be sussed out, hypotheses have to be made, analyzed/tested, and "good" *conclusions* drawn, before we can begin to know what really needs to be done in a given situation. Only then can we begin to piece together the parts that might solve the problem.
  
  This a much bigger problem than, "these products/technologies are good," and, "those are bad." That is the most simplistic sift that *always* has to be made; but even the "good" products can only be sanely utilized within the scope of their own strengths and weaknesses.
  
  When "security" is built directly into a product's core, if it isn't scrupulously standards-based and intended to be fully interoperable according to those standards, we wind up with more proprietary crap that deliberately creates new gaps along its seams.
  
  We abhor and ignore complexity.
  
  An EasyButton is fine for photocopiers and buying office supplies.
  
  There is just no such thing in RealWord InfoSec.

  October 25, 2007

  0 replies

• "defect" revelation is win16 lurking in Ring0 on win32/win64
  The revelatory "new" defect isn't "code-in-data" or even specifically graphics image file formats.
  
  Yes, of course, those are real problems.
  
  The revelation is that win16 code, lurking in strategic, Ring0, WinOS-innards, like GDI32.DLL, are capable of severely compromising win32 and win64 OS-es.
  
  Two things need to be done about this:
  
  1) No win16 code should be running in Ring0 on a 32-bit or 64-bit WinOS.
  
  MS moved GDI32.DLL into Ring0 as part of some Sevice Pack to Win2k. This was done, at the behest of "gamers," to speed up graphics operations in the all-in-one W2k OS. GDI32.DLL continues to run in Ring0 on all WinOSes since then.
  
  People who knew better at the time, balked when MS did this; but MS proclaimed that there would be *no* security or stability implications of moving GDI32 to Ring0, because the code in GDI32 had "proven itself" in the real world.
  
  To that, we must now say, pshaw...
  
  What other WMF-flaws will turn up in GDI32.DLL that are software defects that originated in the pre-NT-era, and were then carried forward into NT3.5/NT4, where GDI32.DLL did *not* run in Ring0, yet are now running in Ring0???...
  
  That any "unauthorized memory access" defects residing in GDI32.DLL might be less severe (as in DoS-only) than the latest abuse of (win16) SetAbortProc is pure accident and not by design.
  
  Not remediating these defects (SetAbortProc, ExtCreateRegion, ExtEscape, ad nauseum), as soon as they become known, is nothing less than MS using its customers to play a dangerous Game of Chicken, always waiting to see if the BadGuys can leverage UMA into Remote Code Execution, before Doing The Right Thing. Of course, MS has no liability whtsoever for any costs/losses incurred by its Defect-Daring Customer Chickens as a result of deliberately delayed patching.
  
  2) With the advent of NT-Technology, MS touted that WindowsOnWindows would protect win32 from crippling effects of known-to-be-crap win16 code.
  The myth of WoW protection is a promise that now needs to be honored and delivered by MS. Win16 needs to be sufficiently and effectively sandboxed, once and for all.
  
  The expedient thing for MS to do would be to summarily kill off "backward compatibility" in future WinOSes; but without 1) above, it's doubtful that MS has a real idea where all of embedded win16 lurks in win32/win64.
  
  After moving all win16 out of Ring0, all of win16 then needs to be rigorously sandboxed, on every WinOS that continues to harbor win16 code in it.
  
  *This* is the "bug hunt"/remediation that MS needs to undertake, if it takes Security seriously and cares about the computing safety of its customers.
  
  It's a Big Deal to Do only because MS has put off doing it off for far too long.

  January 11, 2006

  1 reply