cygwin security in sensitive production

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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.


Re: cygwin security in sensitive production wrote:

Quoted text here. Click to load it

Two things come to mind:

- Security on processing arbitrary data. What happens if your Bash Script
running within Cygwin stumbles on strange filenames? This might lead to
execution of arbitrary code or other induced misbehaviour.

- 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.

Re: cygwin security in sensitive production

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, wrote:
Quoted text here. Click to load it

Re: cygwin security in sensitive production

Quoted text here. Click to load it

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
container (and only UNIX-type names will be allowed in the container).
The only Cygwin piece  thing that's going to look outside the
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
on long names,  but we probably can make sure that names aren't too
on the whole Windows box.

Quoted text here. Click to load it

OK. We shall watch for not running multiple instances. This should be
not too difficult - the load is very moderate,  no incoming traffic to
(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.

Quoted text here. Click to load it

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
this way, so I hope this should be possible for our team,  too.


Re: cygwin security in sensitive production wrote:

Quoted text here. Click to load it

I'm rather thinking about parameter injection and path traversal. For
example, what happens if I include the string "$(foo)" in the filename
whereas your script uses that variable? It might allow the attacker to
escape a path restriction, probably making your script modify various
system binaries.

Quoted text here. Click to load it

See above. This won't help against a bad script. The only real solution is
to carefully audit the script regarding such corner cases.

Re: cygwin security in sensitive production

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

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

Site Timeline