Making more sense of service SDDL

Thanks to Dana Epp’s blog for drawing my attention to Microsoft’s rather easier-to-read explanation of SDDL as it applies to services in the KB article “Best practices and guidance for writers of service discretionary access control lists“.

Oh, and of course, thanks to Microsoft for explaining it all.  I’m sure I’m not the only service author or administrator that has been confused by the SDDL output from “sc sdshow”.  Now, if only we could get some tools that would allow us to surf through DACL-space…  I’m brainstorming for ideas, but haven’t yet had any that I can put into code.

The really scary part about DACLs, of course, is that anyone can create a new secured object, and define what the various bit-fields of the ACE mean… there’s no good way to enforce documentation of security flags, and (as we’ve seen here) few tools or documentation already existing that help you interpret even the system-enforced security object DACLs.

Sometimes it’s good to be a foreigner

Every now and again, I go looking to foreign versions of various web sites – mostly, because of my own background, I go to UK sites (because that’s where I grew up), or US sites (because that’s where I live now).

Here’s a UK gem that US developers aren’t aware of: – MSDN Nuggets – a 10-15 minute exposition on a developer topic, for people who are too short for time to make it through an entire one-hour webcast (and I’ve met very few developers who can sit still for a whole hour).

Then there’s the sites where I don’t even read the language – but in the case of Microsoft’s Japanese Security pages, you don’t have to!  [Wouldn’t it be nice if the English Security notices included such a simple demonstration of how an attack can proceed?]

Of course, for the most part, the feeling is the other way around – the US sites get all the best offers, the new features, etc, etc, but occasionally local ingenuity allows you to get something useful from a site outside the US.

Broaden your horizons – there’s a whole world of information out there, and it’s all as close as your desk!

SDDL – easier to read, except when it’s not.

SDDL was introduced by Microsoft in Windows 2000, as a counter to the difficulty developers had in writing (and administrators had in reading) Security Descriptors, and specifically the Access Control Lists that come with them.

The recent advisory about service security settings (the title says “possible vulnerability” – as far as I’m concerned, it’s definite – I’ve exploited it on a couple of our own machines in XP SP1) led me to check on some other services, particularly the one that I make and sell.

My service turned out to be alright, and then a friend emailed me to ask about our favourite target: Quickbooks.  The new Quickbooks 2006 includes a system service.  I got Susan to list the SD on the service:

 C:\Documents and Settings\Administrator>sc sdshow QuickBooksDB


Wow – that’s confusing, isn’t it?  Okay, let’s deconstruct it – “D:” at the start indicates it’s a “Discretionary ACL” or “DACL” – this is a list of things that users / groups can / cannot do.  The “S:” towards the end is for a “SACL” – “System ACL”, which lists what gets logged.

Let’s look at a sample DACL Access Control Entry (ACE):


The “A” means “Allow” – this ACE lists what the user is allowed to do.  The “SY” means that the user being described is the local system.

The rights in the middle are made up of selections of pairs of letters:


So, that explains it, right?  Well, not exactly – what does it mean to “Create Child” on a service?  To “List Child” on a service?

After a lot of looking, I find that there really isn’t any sensible meaning to those.  The trick is to ignore those names.  Instead, think of the pairs of letters as representing numbers:

CC is listed as being equivalent to SDDL_CREATE_CHILD, or ADS_RIGHT_DS_CREATE_CHILD – and that last name has the value ‘1’ in the header file IADS.H.

Oh yes, you have to have the Platform SDK or other source of Windows Include Files to figure this out.

Then you go to the header file WinSvc.h, and find that SERVICE_QUERY_CONFIG is a right, and has the value 1.


To help you, I did the work and came up with:

CC – SERVICE_QUERY_CONFIG – ask the SCM for the service’s current configuration
LC – SERVICE_QUERY_STATUS – ask the SCM for the service’s current status
SW – SERVICE_ENUMERATE_DEPENDENTS – list dependent services
RP – SERVICE_START – start the service
WP – SERVICE_STOP – stop the service
DT – SERVICE_PAUSE_CONTINUE – pause / continue the service
LO – SERVICE_INTERROGATE – ask the service its current status
CR – SERVICE_USER_DEFINED_CONTROL – send a service control defined by the service’s authors
RC – READ_CONTROL – read the security descriptor on this service.

SDDL turns out to be absolutely no use whatever in figuring any of this out, and I couldn’t find a tool on Microsoft’s site that adequately lists service rights in such a way that an admin might understand them.  Maybe I’m just not looking in the right place – if you know of any, please let me know!

Is it any wonder that there’s a difficulty with service writers and administrators incorrectly setting access rights?  How do you guys configure security descriptors on objects like services?

"Windows Access Control Demystified" – demystified.

There’s been a little fuss raised in security research circles about a paper by Sudhakar Govindavajhala and Andrew Appel, titled “Windows Access Control Demystified“.

From looking at what it does, the paper quoted is actually surprisingly simple – but there is brilliance in the decision to attack the problem (who would guess it was a tractable problem?) and make it so simple in the first place.

Sudhakar & Appel use Prolog – an old, old, old AI language – to document simple logical predicates and conclusions, such as “if group G can access a resource R, and user U is a member of G, then U can access R”, which is really easily expressed in Prolog.  The real goodies are conditions like “if U is compromised, and U can write to R, and user V can execute R, then V is compromised”.  Then he just lets Prolog go off and do its thing.

Prolog’s “thing” is to take such a list of conditions, and a few starting axioms (the two obvious ones Sudhakar uses are “user Guest is compromised”, and “a Restricted User is compromised”), and infer conclusions such as “Local System account is compromised”, or “Administrator account is compromised”.

Embarrassing fact: that’s nothing surprising – we’re all well aware that there are likely to be numerous routes to compromise hanging around in most systems.  These are called “privilege escalation attacks”, and they are why good administrators pay attention to what their users do even after they have restricted them as to what they may do.

The joy of Prolog is that it tells you how it got to its answer.  For instance, in the case of yesterday’s Microsoft Security Advisory 914457, it’ll tell you that if the Restricted User is compromised, the Local System is compromised because the SSDP service can be configured by any Restricted User to run any executable under any account.

Most of the task of creating the input to Prolog can be done automatically, by analysing the system’s current configuration and generating lists of access privileges to system objects.

I hope that this tool – or something like it – will initially be used by Microsoft to help lock down their systems, and later be used by application developers to help lock down their own application installs; eventually, it would be nice to find it in place in businesses, where system administrators would use it (among others) to keep track of their security exposure as they change configurations.

Sadly, I predict that it will be used at greater speed by hackers and crackers in order to find and exploit vulnerabilities.

Expect a rash of security advisories from Microsoft and third-party software developers, and a number of viruses that use these privilege-escalation exploits along with standard social engineering to attempt to gain access to your systems.

However, it is important to note that this tool does not discover points of entry – it assumes that you already have some access to the system, either as Guest, or as a Restricted User. 

The best way to keep these elevation of privilege attacks from being a bother to you is to not grant any privilege to people you can’t in some way trust. 

The information in this paper cannot be used to create a worm, because it does not document or examine the points of entry into a system.  As with all security tools, even if you fixed all the problems it reported, you couldn’t say that your system is secure, because the tool is only as good as the data it gets – and that data is going to be incomplete.  Tools alone cannot secure a system.

AOL, Yahoo introduce "pay to spam" service.

Okay, so that’s not exactly what they call it, but really, what else are we supposed to read into this announcement?

New Service Would Charge E-mail Senders

[Note, that’s Yahoo’s web site, so it might be a teensy-bit biased on the story.]

Here’s a quote:

“[Yahoo and AOL] plan to introduce a service that would charge senders a fee to route their e-mail directly to a user’s mailbox without first passing through junk mail filters”

Uh, yeah, that sounds like “sell access to their users’ inboxes to spammers”, in any other language.

How much is your spam-free inbox worth?

“The fees, which would range from 1/4 cent to 1 cent per e-mail” – kinda cheap, compared to junk snail mail.

Maybe they could spin the service a little more for us?  Yes, the sentence continues: “are the latest attempts by the companies to weed out unsolicited ads, commonly called spam, and identity-theft scams. In exchange for paying, e-mail senders will be guaranteed their messages won’t be filtered and will bear a seal alerting recipients they’re legitimate.”

Let me get this straight… if I’m one of your customers, you’re going to sell access to my inbox, to anyone who has my address, allowing them to bypass the spam filters that would normally have kept them out of it, and this is to “weed out … spam”?

How exactly does that work?

Sounds crazy to me.

Thank goodness I control my own spam filters, and I’m not a customer of either Yahoo’s or AOL’s.

A final quote from the article:

“AOL and Yahoo would get a cut of the fees charged by Goodmail.”

So, that’s alright, then.

Update: The BBC’s news web site has an article at that suggests that this will reduce spam by making it too expensive to spam.  If the filters currently in place aren’t already stopping spam, how will this change?  And if I’m a bona-fide company whose legitimate mail to willing recipients gets caught in Yahoo / AOL’s spam filters, do I have to pay to get my mail to my customers?  Where’s the incentive for AOL / Yahoo to make their spam filters accurate, since they are going to “get a cut of the fees”?

Sometimes it’s hard to be a developer…

I’ve spent a while adding new features to my FTP client, and you’ll get to see some of that in a month or two, when it all comes together as a release.

One of the latest is “drag and drop” – and I went searching for advice on how to do the drag and drop from “virtual folders” – i.e. when the files don’t exist locally until you actually do the drop.  So you can’t do the easy method of passing a file location to the drop target.  I found a great document that perfectly describes what I need to do:

“Handling Shell Data Transfers”

Great, clear, simple advice (simple, if you’re a developer) on how to do drag and drop – and it serves a second purpose, that of cut/copy and paste.

So, I get the drag and drop working, and then I go to look at the cut/copy and paste, and add the few lines of extra code needed.

It doesn’t work.

I realise quickly that the following lines are the problem:

7. When the paste is complete, the target calls the IDataObject::SetData method with the CFSTR_PASTESUCCEEDED format set to DROPEFFECT_MOVE.

8. When the source’s IDataObject::SetData method is called with the CFSTR_PASTESUCCEEDED format set to DROPEFFECT_MOVE, it must check to see if it also received the CFSTR_PERFORMEDDROPEFFECT format set to DROPEFFECT_MOVE. If both formats are sent by the target, the source will have to delete the data. If only the CFSTR_PASTESUCCEEDED format is received, the source can simply remove the data from its display. If the transfer fails, the source updates the display to its original appearance.

No matter how much I try, I can’t get CFSTR_PASTESUCCEEDED into my SetData method.  I get the CFSTR_PERFORMEDDROPEFFECT format, so I know I’m setting it up correctly, but I get no CFSTR_PASTESUCCEEDED.

Days of trying different code, different ways of triggering the paste, go by, and I finally realise that there is no CFSTR_PASTESUCCEEDED coming from Windows Explorer – and since this is the de-facto drop target, that’s exactly the model that is going to be followed by every other drop target I’m going to meet.

I’d really love to tell Microsoft about this, and get the documentation fixed.  This used to be dead easy – I’d click on the “SDK Feedback” button, and send an email.

No “SDK Feedback” button any more.

Why not?  Where did it go?

What’s in its place?  Nothing terribly useful – a link to a web page that I can fill in.

Can I attach a file of source code to demonstrate this?


Can I italicise words that are important?


Does the web page offer any extra capabilities that can’t be done in an email?


So, why did this happen?  Beats me.

I finally decided to give up and ignore CFSTR_PASTESUCCEEDED entirely.  It seems superfluous.  I do find it thoroughly irritating that my time is wasted once again, because I tried to follow specific documentation that turned out not just to be wrong, but to have unnecessary, and incorrect, extra detail.  This isn’t the first time (the last time was when I was following documentation on how to close SSL connections), and I doubt that it will be the last.

Some guidelines about fax.

Susan Bradley, SBS Diva and Security Guru Extraordinaire, posts about some guidelines for making your fax modems work reliably over at

This reminds me that I am continually amazed by people who call our company asking for instructions on faxing us – not because they want to fax us, but because of why they want to fax us.

Their perception is that fax is more secure than email.

I’ll pause while you think on that.


Okay, so here we go…

  • Data Encryption: A fax cannot be encrypted, but an email can. Sure, there are some encrypting fax machines and/or software, but the ones I’ve seen all require that your peer has the same machine / software; email has standardised encryption methods – the most common of which is S/MIME.
  • Peer identification: An email can be diverted by hijacking the DNS settings in the sender’s DNS servers for the recipient’s domain – possible, but hardly trivial (and resolved by using encryption with a peer whose certificate you know). A fax can’t be so easily diverted, but when a company moves, its phone number gets assigned to someone else. That explains why we get a number of faxes every week for a rock quarry; some of these include ordering information.
  • Non-repudiation: again, S/MIME and others come into their own here, by providing the ability to sign an email. You can’t sign a fax, except with a hand signature that is so ludicrously easy to duplicate (cut it out of a previous fax, and paste it onto the next one).
I’m normally all over the idea that users should be using solutions with which they are comfortable, and whose failure modes and security mechanisms they are already familiar with – but it seems like too few people have ever considered these issues for facsimile machines, and they’ve all been told that email is unsecure.

By now, we should all be comfortable sending signed and encrypted messages, using self-signed certificates.

Update 2006-02-07: Prudential’s customers have their data sent, by the thousands, to a herbal remedy store, because the two fax numbers differ by only a digit.  Private information should be sent through secure channels – fax is not a secure channel.

Feb 3, 2006 – Virus destroys data on a million machines…

Okay, so that’s a future headline, and it’s possible / likely that the damage isn’t going to be quite that bad.  But the virus reports back to a home web site, increasing a counter as it does… the counter is well past a million.  [Okay, so that number is likely to have been added to by people trying to make fun]

However, the virus under discussion (as usual, it goes by several names, including Nyxem, Mywife.E, etc) is something that doesn’t come along too often lately – a deliberately destructive virus.

It’s programmed to trigger on Feb 3, 2006, and every third of the month thereafter.  You have only a few days in which to check that you aren’t engaging in the sort of behaviour that gives you this virus, and that you have scanned your systems, and removed it if it has been installed.

Microsoft’s {Malicious Software} {Removal Tool} won’t help you, because although it will remove the virus, it will only be updated on February 14, its regularly scheduled release date.  Not really the best idea in terms of timing.

Microsoft does have tools available to protect you, though – there’s a page at that describes the virus and gives manual detection and removal instructions, as well as pointing you to the beta programmes for Live Safety and OneCare, which are both already able to detect and remove the virus automatically.

Behavioural changes you should make – don’t open attachments.  Really, just don’t.  Random other individuals do not have naked pictures of your wife, and those pictures from the Kama Sutra, well, they aren’t.

Even if an email comes from someone you know, don’t open the attachment.  Really, just don’t.  If you still feel like you absolutely have to, please at least call them and verify that they sent you the attachment, and to ensure that the attachment you see is the attachment they sent.  Ideally, exchange digital certificates and use signed mail – that still won’t totally protect you if a virus can access your friends’ email application, but it’s a damn good start.

Peculiar article on "new kind of bug".

So, I’m cruising the security news feeds, and I come across this interesting little article: Microsoft to hunt for new species of Windows bug

I really don’t think the article is all that fair – maybe Kevin Kean and Debby Fry Wilson weren’t able to convince the journalist to write the whole side of the story, I don’t know.

Certainly, while I was at Microsoft, new code was run through code-review by real, intelligent people, with a keen eye to ensuring that it could not be abused; new features were run through threat-modeling by a Security PM, whose job it was to find all kinds of avenues of misuse and abuse, and rate mitigiations and risk.  I don’t believe that approach was unique to IIS.

So, far from this being something that’s completely new to MS, and has never been addressed, this is something that’s looked at for new code all the time.

Old code, I’m not so sure of, and maybe the article is right in that regard, that old code is not scanned rigorously for unintended uses.

What software company out there is currently scanning through old code for such unintended uses as a regular part of their security process?

Okay, so we do it here at Texas Imperial Software, every time a new and interesting abuse is revealed against someone else’s software, but that’s a much smaller segment of code.