Secure functions

[Rick C. Hodgin]

I had an idea that perhaps C and C++ could both benefit from: the addition
of an ability to create secure functions.

int functionName(int a) secure
{
// Normal code starts here

} unsecure {
// If an unknown function attempts to call, falls through here
// If after a test, to actually enter the function simply
// call it from here, as the compiler will know this call and
// establish the token validation for you.
return(functionName(a));
}

By adding this feature, and the ability to tag this "unsecure { }" block
to the tail of the body, the compiler could assign a random value that
is placed in a register (or passed as an extra invisible parameter),
which can be scrutinized upon entry to make sure it's coming from a
known location. It would be known because the compiler would inject
the requisite code to meet the conditions of the test it also injects.

As such, only known-at-compile-time calls to the function would be
guaranteed to come from a source that contains the token, making
secure access into the function something that can be known.

Simple function entry test:

; void functionName(void) : secure
cmp rax,_this_functions_secure_token_number
jnz branch_to_unsecure_entry

; Normal code starts here

With this test, and by placing the code in an execute-only block, it would
prevent external callers from being able to call unaware. It would require
intimate knowledge of the executable on disk, for example, as these tokens
could be completely randomized during installation, or when by the OS at
the very instant the application is launched and loaded from disk.

It would also provide some known information about whether or not params
passed by reference are, in fact, NOT NULL (because the compiler will not
assign NULL values to pass in, and then only if the unsecure block is
entered would any passed parameters need to be tested for NULL, for
example. Or, in the alternative, the caller could be flatly rejected
and some kind of error or warning given for the unexpected intrusive
access).

This security would incur a minimal performance hit, and provide
the ability to know that the code in the project is the only and
actual code being used to call the function. It would be a way to
prevent unwanted, or unexpected access to something that shouldn't
have it.

Best regards,
Rick C. Hodgin

[Leonardo]

In what scenario would a function call be insecure? When malware or a
debugger calls it outside the regular program flow?

If so, couldn't the said program check the CMP instruction of a function
to get access to the secure token? Or better yet, stop it from jumping
to the insecure part?

--
Leonardo

[Rick C. Hodgin]

> In what scenario would a function call be insecure? When malware or a
> debugger calls it outside the regular program flow?

When it is called without knowing the token.

The idea is the compiler generates a random token when it creates the
executable. Every known call to that function will setup the token to
be tested by the called function. If you call through a pointer to the
function's address, you won't have the token setup except by something
like random luck or a brute-force attack. And, because of that
possibility, I think the better solution would be for the OS loader to
do some load-time linking on the binary and introduce random values for
each secure function, so that every time the binary is loaded, it has
a new set of random values.

> If so, couldn't the said program check the CMP instruction of a function
> to get access to the secure token? Or better yet, stop it from jumping
> to the insecure part?

It would require the code be loaded into and running from an execute-only
block of memory. By doing that, no external application would be able to
gain access to the raw binary/machine code to be able to determine the
token, and the front-end could be created in such a way that only a proper
landing point, with a proper token or not, would be valid entry into the
function.

Different kinds of tokens could be created. However, I think for speed
reasons the need to test a 64-bit value would be sufficient. The odds of
happening onto the exact 64-bit random value assigned during this binary's
launch ... it's just unlikely.