Mail Archives: cygwin/2007/09/20/11:54:19
On 20 September 2007 10:09, Warren Young wrote:
> Will Parsons wrote:
>> why would cygwin be less secure?
> Just one way it could fail is if there is a buffer overflow in the
> implementation of one of Cygwin's interfaces, and your "100% secure"
> program calls it. It's then only a matter of time for a skilled hacker
> to turn that buffer overflow into an arbitrary code execution
> vulnerability. At minimum, the hacker will then have the privileges of
> the program. Once the hacker has local access, chances are good that he
> can parlay that into a privilege escalation attack, and it's Game Over
> for you.
It's worse than that - he's dead, Jim. Cygwin does actually introduce one
gaping security hole: the shared memory section.
It's an artifact of the fact that we're trying to emulate an entire posix
system, and so we need to maintain global state across multiple processes.
Because we're not the kernel, we can't just keep process lists and so on in
kernel memory where all processes can access them, so we have to find a way of
sharing memory between different processes in used mode; the shared section is
a way of doing this.
Unfortunately, that means that low-privilege processes (running as a limited
user) and high-privilege processes (running services as SYSTEM, for example)
have an uncontrolled connection between them. It's entirely likely that a
guest user, by manipulating the contents of the shared memory section, could
inject code into or otherwise divert or seize control of any SYSTEM-level
cygwin process.
That's yer privilege escalation right there, that is.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -