Re: Library Design, the script kiddie's nightmare.

f0dder,

Now here are the next problems with your assertion about the effects of
an unhandled exception in either Unix or Windows.

1. Both OS versions are drammatically different yet you assert that
they have the identical security leak.

2. You are asserting that ANY buffer overflow will break the security
of two entirely different OS versions.

There is a method of dealing with a problem of this type, report this
major security flaw to the respective OS vendors and see if they agree
with you. i would not hold my breath waiting

Can't you read? Quoting myself, with some emphasis added:

"it's common to have *non-root* access to a unix box." - that's what you get
from a shell provider.

Same question for someone who seems to think they are new found Unix
expert, are you claiming that allowing "root" access is not a security
problem ? Many Unix hacks of old were based on gaining "root" access
and this will be of course from first having "non root" access first.

"If a "sudo" application (ie, privilegeded binary that can be run by
non-root) has a buffer overflow, a non-root user can privilege escalate to
root. This is bad. And that's the kind of stuff your GetCL could cause."

GetCL simply does not run on Unix so this is clearly nonsense. Windows
API functions do NOT run on a native Unix system. If you dont know
things like this you need to go back and learn them.

If you are confusing things as basic as code compatibility across two
entirely different native operating systems you need to give up
lecturing others and start learning these basic distinctions.

Lack of research seems to be a common method in your approach, the
solution to someone using the old algo where there is a high chance of
too much data being pointed at it is contained in EXAMPL10\STEXP\SE.ASM
within the masm32 Project.

This is the RIGHT WAY to deal with a component algorithm of this type,
forget padding the code full of junk that restricts the user.

Regards,

hutch at movsd dot com

.

Relevant Pages

  • Re: Mac OS X Security - Not Quite as Strong as you Thought
    ... That's the standard Unix way. ... But then if an RBAC is set up only for one certain user to a couple of certain tasks that require root but only selected programs, then it would be more secure, as Sun suggests. ... That's probably why the majority went windows early on. ... so far it isn't that bad for security with OS X currently. ...
    (comp.sys.mac.advocacy)
  • Re: Process.Start()
    ... I understand having qualms over security. ... I've been in the unix world ... for quite a while and realize the danger of running under root. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: secure UNIX log server
    ... We are storing them a seperate UNIX "log ... The log server is physcially secured ... >> UNIX administrators authorized to use the root acount. ... >> administrators on the log server and give it to the Security team. ...
    (comp.security.unix)
  • Re: secure UNIX log server
    ... We are storing them a seperate UNIX "log ... The log server is physcially secured ... >> UNIX administrators authorized to use the root acount. ... >> administrators on the log server and give it to the Security team. ...
    (comp.security.unix)
  • Re: Huh. There are actually "Macs Suck" websites?
    ... You made an assertion that Sun managed to do what no other company had ever ... done - find a way to marry the power and flexibility of Unix with the ease ...
    (comp.sys.mac.advocacy)