[Info-vax] VAX Macro to C conversion

[Craig A. Berry]

On 7/25/19 7:18 PM, Simon Clubley wrote:
> On 2019-07-25, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2019-07-25 00:36:27 +0000, Craig A. Berry said:
>>
>>> On 7/24/19 8:28 AM, John Reagan wrote:
>>>>
>>>> DECC$ATOI                       = PROCEDURE,-
>>>> DECC$ATOL                       = PROCEDURE,-
>>>> DECC$MEMCHR                     = PROCEDURE,-
>>>> DECC$MEMCMP                     = PROCEDURE,-
>>>> DECC$STRCAT                     = PROCEDURE,-
>>>> DECC$STRCHR                     = PROCEDURE,-
>>>> DECC$STRCMP                     = PROCEDURE,-
>>>> DECC$STRCPY                     = PROCEDURE,-
>>>
>>> Yum, ASCIZ string functions with no bounds checking in the kernel :-).
>>> Probably not the most dangerous thing out there, but possibly worth a
>>> rethink at some point.
>>
>> Not only in the OpenVMS kernel code, but also third-party inner-mode code.
>>
> 
> Careful Craig and Stephen. :-)
> 
> Counted strings and/or descriptors are not some magical fix for
> buffer overflows.
> 
> They are a lot harder than ASCIZ strings to compromise, but once
> compromised, they can be way easier than ASCIZ strings to exploit
> for some types of attack.
> 
> That's because with counted strings/descriptors, you don't have to
> worry about embedded 0x00 characters terminating the copy so you
> can just directly embed addresses as-is (including 0x00 characters)
> without having to worry about the copy terminating when the first
> 0x00 in your payload is encountered.
> 
> Overall, counted strings and descriptors are way better than ASCIZ
> strings but they are not a magical solution and come with risks of
> their own.
> 
> However, as Stephen mentioned, it would also be nice to see safer
> versions of the ASCIZ routines introduced and the non-safe versions
> depreciated for kernel mode code.
> 
> Notice BTW that I said "safer". I did not say "safe".

Notice BTW that neither I nor Hoff ever said anything about string
descriptors nor counted strings, so why you chose to bring those up in
this discussion is a mystery.

Specifically, I said "ASCIZ string functions with no bounds checking."
A function that provides a mechanism for checking the maximum length of
an ASCIZ string is what the actual and de facto standards do.  De facto
being strlcpy and friends from the BSD folks and mostly adopted with a
bit of whinging by the Linux folks, or strcpy_s and friends from the
Microsoft folks, the latter of which did/paid more to influence the
latest standard such that it has the Annex K with the "_s" functions in
it, but which no one but Microsoft is likely to implement as part of
their standard library.

There are differences of opinion about which interfaces are least likely
to be subject to programmer mistakes, but the basic principle of
checking buffer boundaries but also stopping on a NUL byte are the same.
And totally different from how descriptors and counted strings work.