cygwin security in sensitive production

Hello All,

We are building an extremely secure environment
(for instance, all UNIX boxes there will be B1 certified).
We also need few Win2003 servers there. Hardening
will be taken care of by a separate Windows team,
but I'm responsible for things like VPN tunnelling,
audit logs, some of local job scheduling,
ssh clients, etc. for the whole site.

For me, as a UNIX person, those things would be
much easier to implement on Windows site throuh cygwin
DLLs and executables - I perfectly understand the risks and
advantages of those tools from UNIX perspective.
What I am lacking is the Windows perspective.
Before I talk to our Windows admins, I need to grasp
a better understanding of risks that one or two
cygwin DLLs and 5 to 7 executables may introduce
to an extremely hardened Win2003 server.

I am familiar with number of critical production sites
that deploy cygwin on Windows for external communications
and local job scheduling, but neither of them had such
paranoid security requirements as we've got now.

Any thoughts, stories, links are highly appreciated.

Thanks,
Andrei

Out of curiosity, how are your Unix boxes configured? I have heard
that mandatory access controls (MAC) are difficult to setup on most
versions of Unix. I am impressed that your organization has them B1
certified. Anything special that you fellows had to do?

J Wolfgang Goerlich

On Mar 13, 6:00 am, aryz...@spasu.net wrote:
> Hello All,
>
> We are building an extremely secure environment
> (for instance, all UNIX boxes there will be B1 certified).
> We also need few Win2003 servers there. Hardening
> will be taken care of by a separate Windows team,
> but I'm responsible for things like VPN tunnelling,
> audit logs, some of local job scheduling,
> ssh clients, etc. for the whole site.
>
> For me, as a UNIX person, those things would be
> much easier to implement on Windows site throuh cygwin
> DLLs and executables - I perfectly understand the risks and
> advantages of those tools from UNIX perspective.
> What I am lacking is the Windows perspective.
> Before I talk to our Windows admins, I need to grasp
> a better understanding of risks that one or two
> cygwin DLLs and 5 to 7 executables may introduce
> to an extremely hardened Win2003 server.
>
> I am familiar with number of critical production sites
> that deploy cygwin on Windows for external communications
> and local job scheduling, but neither of them had such
> paranoid security requirements as we've got now.
>
> Any thoughts, stories, links are highly appreciated.
>
> Thanks,
> Andrei

> - Security on processing arbitrary data. What happens if your Bash Script
> running within Cygwin stumbles on strange filenames?

Depends on what it uses those names for, I guess..
I doubt there may be a buffer overflow flaws in the shellcode, but
anyway,, we shall try to avoid running shell scripts outside the
cygwin
container (and only UNIX-type names will be allowed in the container).
The only Cygwin piece thing that's going to look outside the
container,
is Tripwire binary. Tripwire, compiled in Cygwin from sour,
has proved to work on strange Windows filenames just fine.
Of course, it has not been tested against things like buffer
overflow
on long names, but we probably can make sure that names aren't too
long
on the whole Windows box.

> - Loader behaviour. At least not Cygwin itself, but some of Cygwin's tools
> might use what's called a ".shared" section, which effectively is shared
> memory among multiple instances of the same binary. If someone with normal
> user rights and an admin are running such a binary at the same time, and
> additionally the program holds security-relevant data in this shared
> memory, it might lead to privilege escalation, since there's no security
> boundary on such kind of shared memory.

OK. We shall watch for not running multiple instances. This should be
not too difficult - the load is very moderate, no incoming traffic to
Cygwin
(it will only push the data, and never pull).
I believe we should be able to control this.

Many thanks, the points you raised, added more to my watch list.

> Out of curiosity, how are your Unix boxes configured? I have heard
> that mandatory access controls (MAC) are difficult to setup on most
> versions of Unix. I am impressed that your organization has them B1
> certified. Anything special that you fellows had to do?

These will run Solaris 10 with Trusted Extentions.
Not sure how Solari's RBAC (Role Based Access Control) relates to MAC,
but there are few B1 certified servers in the house built by other
teams
this way, so I hope this should be possible for our team, too.

Regards,
Andrei

I'm a novice at official security, but never use a shell script to
process user input. Write what you want to do in C (say) and all
user input is just data.

I remember a long series of breakings-in against successive scripts
somebody was writing to do mail return receipt, fixing each breaking-in
one at a time, that went on for weeks. There's always another way
to get past a shell script.

The last one, before the guy gave up completely, was setting the
high bit on ascii to escape detection, eg. ` with the high bit set.

--
Ron Hardin
rhhardin@mindspring.com

On the internet, nobody knows you're a jerk.