Mirsad Todorovac wrote:
(But so did Mr. Brian Kennighan, right? With introducing gets() that cannot be protected from overruns he was laying the system's security on wrong assumtion. And I deeply respect him and do not think he was stupid or incompetent. Simply the users were different at that time, and they were behaving.)
I was laying my code on wrong assumptions on safety, extensivelly using strcpy(), memcpy() and similar functions that leak the water. I assume that novice programmers would do the same
Which emphasizes that C is not a good language for novice programmers. Even more so in potentially security criticial settings ...
These kinds of things are really not so easy to get wrong by accident in Pascal (even though GPC doesn't provide 100% security automatically).
(of course, today CGI is mostly replaced by PHP and perl "preempted" C for the purpose, but then again leaving the possibility to write CGI programs that leak is a bad security policy. Disabling them completely is something I do not prefer since we are University and that would cripple student's opportunity ot learn. Even learn on errors). Then, having instelled a CGI program that has security hole without knowing that, I could rely only on obscurity of code to keep the attackers away.
CGI programs written by any ordinary user can certainly a problem. What you can do is at least make sure they are executed with the user's id, not the web server's, so a mistake would at first only compromise the account of the user who made the mistake. Then you only have to worry about local-user root attacks ...
More strictly, you could run user's CGI programs in a sandboxed environment as I said. E.g., on our GPC web server, some contributors have SSH accounts. They run in a UML (User Mode Linux) environment, so even if they had their own CGI programs (which they actually don't (yet?) in this case), and those were attackable, and the attacker then gained root privileged by another, local-user exploit, they'd only be root in the UML, which again runs under an unprivileged user ID on the real system. So they'd need another exploit against UML to get really elevated privileges. And since UML is made for exactly this purpose, I'd think it's audited for security by some experts and problems getting fixed rather soon.
I think "security in depth" in the buzzword here. Make an attacker require several independent exploits in order to achieve anything.
Looking at Microsoft policy of obscurity that simply does not work and we are brought down to our knees with every new kind of virus I came to think something ought to be done on system level. Essentially, using Perl or Java would eliminate 95% of buffer overruns implicite.
And probably replace them with other kinds of failures.
And, as Adriaan said, the remaining 5% are probably the most dangerous ones.
Frank