Re: baffled by efs
From: cquirke (MVP Win9x) (cquirkenews_at_nospam.mvps.org)
Date: 12/29/04
- Next message: Carey Frisch [MVP]: "Re: Virus in my restore points"
- Previous message: jra1951: "Virus in my restore points"
- In reply to: Steve Riley [MSFT]: "Re: baffled by efs"
- Next in thread: Steve Riley [MSFT]: "Re: baffled by efs"
- Reply: Steve Riley [MSFT]: "Re: baffled by efs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 29 Dec 2004 15:28:26 +0200
On Tue, 28 Dec 2004 11:22:23 -0800, Steve Riley [MSFT]
> cquirke again
>> On Mon, 27 Dec 2004 13:30:03 -0800, Steve Riley [MSFT]
>>> Each person's RMS lockbox is stored in %USERPROFILE%\Local
>>> Settings\Application Data\Microsoft\DRM. Once you complete the
>>> registration process, your lockbox is no longer a single DLL but a
>>> series of files
>> And they aren't scoopable, one hopes; I see you use NTFS permissions
>> etc. to raise the bar, but it's only a bar if you're "outside".
>"Scoopable?" Meaning copyable between computers that are both
>on the "inside?"
Yes - IOW, I scoop the data files, plus the repository for the keys,
and then I "restore" them to an arbitrary PC.
I'm challenged to see how the system can facilitate restore on to an
arbitrary (replacement) PC while blocking the above scenario, and the
only solutions I can see is some part of the puzzle that has to be
kept out-of-band, e.g. on a USB stick locked up somewhere.
>Won't work. The lockbox customization process builds uniquely-identifiable
>lockboxes for each computer. If you try to copy the lockbox files from one
>PC to another, the RMS client will sense this and the lockbox files will
>self-destruct.
What if the PC is lost, i.e. destroyed or stolen?
>> Changing the month to look up dates etc. changes the date when you
>> close the dialog, unless you are careful to undo, even if you
>> carefully didn't click on any dates while fiddling.
>On NT/2000/XP/2003 only local administrators have permission to adjust system
>clocks. This can be a mitigator.
Well-phrased, as it's a band-aid, and an optional one at that. But as
we're talking about an off-by-default functionality that is to be used
within a properly-administered setting, it's not unreasonable.
I imagine many such installations will also be using Kerberos, which I
understand has even more rigorous timing sensitivities.
Perhaps all that needs to be done is to stress the need to manage RTC
rights, and perhaps re-visit the "time" dialog box so that only
changes committed by "OK" (perhaps through an "Are you sure/nuts?"
confirmation) have any effect at all.
As it is, and as posted, it seems as if that dialog box is "live";
changes may be undone if the user [x] or Cancels, but by that stage,
something that monitors RTC in real time could have pulled the pin.
>> And you need to backup the RMS data set, surely? Implies that theft
>> of a backup gets both half of the puzzle.
That's an extension of the "scoopability" thing mentioned earlier.
I can see a pattern here - that if you deploy this technology, it's
crucial that related settings are sanity-checked and possibly
maintained on an ongoing basis. Else we may see reports of "holes"
that are just a mismatch of unrelated settings, but damaging press.
>You can also store keys on a hardware storage module (HSM),
>which is an effective form of key backup that also increases
>security considerably.
Ah; that's the "out of band" thing I was thinking of earlier. That's
far better than to expect the user to be the HSM hardware, as a
"password" would do. Just as PCs fare badly at being human, so humans
fare badly at being reliable dumb hardware :-)
I can see USB sticks playing new roles that may require some attention
at the raw driver code level, just as one extends other security deep
down into post-FATxx file systems.
>>>> There may be an additional risk, beyond EFS, when it comes to VBA or
>>>> macro infection of "data" files. An av running on EFS may be able
>>>> to scan files, but this is likely not the case here. So I'd want to
>>>> rip out or totally suppress any scripts, VBA, macros etc. within
>>>> these files, as these would be well-positioned to export file
>>>> contents.
>>>>
>>> Correct.
>>>
>> Are there ways to force suppression or stripping of such content?
>
>Outside of Office there's no way to inspect the rights-protected (encrypted,
>remember) files to see whether they contain macros.
That's a re-statement of the problem, which IMO is a serious one.
>There might be a way to set a global no-execute within Office,
>but I don't know about that... I'm a security guy, not an Office guru! :)
I'd be inclined to build it into Rights Management itself - i.e. a
hard setting that dumbs down file content to safe levels if it is to
be hidden from the system by encryption.
We've already seen how password-encrypted .zip, combined with quite
plausible SE, can be routinely used to bypass av. After all, it's
been how we've submitted malware samples to av vendors for a while now
(or for me, anyway... "the password is 'This is a VIRUS!!' " etc.).
Heh, I'm waiting for the first such malware to claim legitimate
software status by a password that is an EULA, e.g. "By opeing this
file I acknowledge the right of the software to..."
The thing is; these things may be intended to do such-and-such, but in
reality, code is neutral. A strong glove works just as well to keep
your assailant's hand warm and safe as it does yours.
>>>> ...a JPEG embedded in a .DOC that exploited the JPEG handler
>>>> to run as raw code could be a problem, if av can't scan the file.
>>>>
>>> RMS isn't a substitute for patching. :)
>>>
>> The length of Day Zero will not always be positive.
>> ....if you want to trust code to behave only as designed, keep it trivial!
>We are in violent agreement here. :) We've done a lot of testing of the lockbox
>handling code, making sure that it rejects unexpected input rather than barfing
>in some insecure way.
Glad to hear that. You'd also want to make sure your code is the only
code that touches the box, and that it's not extensible, and that the
next generation of devs to version it up maintain your prudence.
>> I'd like to have faith in the non-exploitability of the internals of
>> the MS Office apps themselves, but that's asking a lot - such as a new
>> and simplified file type with trivial interpretation code, that could
>> be considered safe to hide within a can't-scan-this wrapper.
>These are good points, and we're thinking about them.
I've wanted to pull a large mass of such concepts together as a
section at my site (http://cquirke.mvps.org) but time etc. :-p
Namely, "depth"...
- assume your defences will fail
- plan what to do when that happens
- don't trust even your own code
- be prepared to amputate subsystems at a moment's notice
- beware of inappropriate "feature sprawl" (e.g. RPC)
...and what I call "risk WYSIWYG"...
- abstract reality towards user's intuitive understanding
- give user clear risk information
- never exceed the risk information the user acted upon
- current risk order may change (e.g. is .jpg safer than .doc?)
...and how that comes down to common realities:
- if user wants to "view" or "read", never "run"
- if user wants to "list", don't delve *into* what is listed
- be bound by visible risk indicators, e.g. file name .ext
- don't auto-integrate newly-discovered drives, even HD (S-ATA?)
- provide safe maintenance tools ("Safe Mode" isn't)
>remember that there are two definitions of "secure": private and inspected.
>When some people mention "security" they mean knowing everything -- inspecting
>all the content. Other people mean "privacy" -- keeping information confidential.
>It's generally impossible to have both!
This is one of the deep and crucial differences between Home and Pro.
Home users lack pro infrastructure. Thier PCs evolve on an ad-hoc
basis, there's usually only one PC that is unique and must survive,
backups are poor, incomplete and may be absent, etc. The user in the
chair should have full and unfettered access to everything. Notional
"administrators" via the 'net or LAN should have no access at all.
Pro IT has strong infrastructure to manage backups and identities, and
is more concerned about unauthorised access than loss. Aside from the
servers, workstations are rarely unique and need not be preserved.
Physical access is extended to semi-trusted personnel that should be
overridden by "the admin", who may work remotely via the network.
The end point crunches down to: Who wins, the guy with physical access
i.e. at the keyboard, or the notional administrator? Because Home and
Pro answer that Q differently, they need to be different products.
>...access controls that work regardless of where the object (file)
>lives and complete privacy outside the access control system.
>The trade-off is your ability to inspect.
It's a particular re-statement of: One admin's maintenance tools are
another "admin's" hacking tools :-)
>And this, perhaps, isn't as large of an issue as you might imagine. Since
>document authors always first create clear-text files on their own computers,
>any virus-scanning system that knows how to look for macro viruses will
>still flag the existence before the file is saved.
Hooyyy... that's like de-bulking a tumour that's already spread
through the bloodstream. Yes, it's a best-case that will reduce the
tumour load, but... for starters; consider the author may be in the
field, working on a corporate laptop that depends upon daily network
access to have the av updated. By the time he's back on the LAN, he's
remembered to apply rights management to his data so it can be
uploaded to the LAN. Any malware will be encapsulated before his av
is up to speed; the opportunity is GFE (Gone For Ever).
This is an old issue for me, when I clean up active malware in the
field, because two sealed malware repositories already exist; System
Restore (which can be purged and rebuilt at the first clean point) and
email mailboxes in most email apps (Eudora's OK there).
What I do in such cases is import the email into Eudora, which causes
all attachments to be split out of the "messages". As long as I
disable "use MS Viewer", Eudora doesn't auto-run scripts of
IE-orientated exploits, so the messages are safe. I can then scan the
attachments, and either work back to delete and purge corresponding
messages in the other email app, or I can say:
"Clean system, or keep your old email. Pick one."
Because you can't rely on detecting exploiters (malware), you may
prefer to exclude risks (malware opportunities).
>RMS does allow you to create document "templates" and enforce their use.
>Again, this is more of an Office thing so I don't readily know the answer,
>but maybe your templates could all be set to refuse the creation of macros.
>Need to research this more, I guess.
It's worth looking at. The thing to remember is that it may appear
that a peculiar set of circumstances that are required to exploit a
risk may seldom occur, they can often be hard-coded into a malware or
library and become pervasive within hours.
>-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
>----------------------- ------ ---- --- -- - - - -
- Next message: Carey Frisch [MVP]: "Re: Virus in my restore points"
- Previous message: jra1951: "Virus in my restore points"
- In reply to: Steve Riley [MSFT]: "Re: baffled by efs"
- Next in thread: Steve Riley [MSFT]: "Re: baffled by efs"
- Reply: Steve Riley [MSFT]: "Re: baffled by efs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
