[Info-vax] Whither VMS?
Jordi Guillaumes i Pons
send.me at no.spam
Fri Oct 2 09:18:30 EDT 2009
En/na Michael Kraemer ha escrit:
>
> The str*() functions exist for convenience.
> If one has problems of that kind, I'd indeed store
> data in a dedicated struct (ptr,len).
>
>>
>> One result of null termination is the easy buffer overflow of
>> many programs today
>
Programmers are, some times, lazy. Specially when they work under
unrealistic schedules and not enough resources. You can find a lot of
things like this in production:
void someFunction(char *someString) {
char aBuffer[1024];
.
.
.
strcpy(aBuffer, someString);
doSomething(aBuffer);
.
.
.
}
The problem is that in C you don't have tools (AFAIK) to catch time
bombs like this one in compilation time nor, probably, in test time. In
higher level languages (COBOL, PLI, even java) you can enable runtime
range checking, and in some cases, even compiletime verification (which
usually gives a WARNING). But not in C. You can have this code working
quietly for years... until a programmer writes something which calls
someFunction() with a 2048 bytes string. Or something who passes a
pointer to something entered by a user. That's when things become
interesting, since in architectures like x86 that can overwrite the
stack frame, and with a well crafted overwrite you can make someFunction
to return to your own bad code.
There are hundreds of examples. Take a look at the CVE reports.
Of course, that could'nt happen in a VAX. All you would get is a ACCVIO,
since VAX has a exec bit for each page, and the stack should not be exec
utable. But on the x86 they have that kind of protection only recently.
I don't know how does this apply to Alpha nor iA64. But on a purely
stack-based, non-execution protected environment like whatever OS on
x86, the NULL-terminated strings are an exploit waiting to happen.
More information about the Info-vax
mailing list