cygwin security in sensitive production

cygwin security in sensitive production

Secure Home | Search | About
 Microsoft Applications Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
cygwin security in sensitive production aryzhov 03-13-2007
Posted by on March 13, 2007, 6:00 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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


Posted by Sebastian Gottschalk on March 13, 2007, 6:25 am
If you were  Registered and logged in, you could reply and use other advanced thread options
aryzhov@spasu.net wrote:

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

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.

Posted by on March 13, 2007, 2:05 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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



Posted by on March 13, 2007, 5:57 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
> - 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



Posted by Sebastian Gottschalk on March 13, 2007, 11:40 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
aryzhov@spasu.net wrote:

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

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.

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

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

Similar ThreadsPosted
Sensitive data in code ... February 28, 2006, 2:08 pm
Using ISP webspace to store Encrypted sensitive data. Comments ?? November 6, 2007, 6:16 pm
Security Breaches Pandemic - Deloitte Touche 2006 Global Security Survey June 27, 2006, 2:10 am
Role-based security from Windows Server 2003 Security Guide gives problems November 6, 2006, 7:58 am
Security discussion regarding hubs, firewalls, anti-virus and Vista Security August 20, 2008, 3:41 pm
Folder Security - Finding Group or User Name in Security settings January 30, 2006, 11:09 am
Unable to Manage Security Settings in Security Center April 14, 2006, 11:14 pm
New site dedicated to security conferences : www.security-briefings.com May 7, 2006, 4:40 am
Vista Security Vulnerabilities showing in Security scan December 14, 2006, 3:14 pm
WinXPSP2 IE 7 Security Zones - security concern November 29, 2007, 12:28 am

The site map in XML format XML site map

Contact Us | Privacy Policy