[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