Should I return meaningful error code in case of internal error?

Question

Let's say I'm using several crypto functions from a 3rd party lib and those crypto functions should never fail because my code, and not a user, is sending all the arguments (buffers, sizes, etc..) so if the function fails it's due to some "internal error". Let's say I have an rsa function and a hash function, my question is:

If those functions fail, should my code return internal_error error code for both failures? Or should it return rsa_internal_error and hash_internal_error respectively?

Returning just internal_error reveals that an internal error and no more so it's harder to debug if my code can return internal_error from several places in one function.

On the other hand, returning a specific error code for each type of failure makes it easier to debug, but also reveals more information to the user.

Which practice is better?

Does returning specific internal error codes can help attackers in their penetrations attempts?

EDIT: This is an embedded systems so we are cheap on logs. Since this error should not occur (it's not dependent on input or something) we usually don't log those errors.

Answer 1

Which practice is better?

It depends on your needs. There is no "secure" or "not secure", only "secure enough for my needs". Which is better depends on your particular risk/benefit tradeoff willingness. As such, this is rarely an answerable question in a security context.

Does returning specific internal error codes can help attackers in their penetrations attempts?

Probably not. You certainly shouldn't be returning stack traces or the like, but a vague error description is probably unlikely to help a would-be attacker. However, a vague error description is probably also unlikely to be very helpful during debugging. As a result I'm going to ask the obvious question:

Don't you have logging on in your system?

For instance, in my API calls if there is an error in production I simply return (a JSON document) that says "Internal Error" along with a 500 status code. This works out well for our front-end developers. When they see that they just stop and come bug me because they know the problem isn't on their end. For my part, I then just go look in my server logs which tell me exactly what happened. There is nothing that can potentially leak to outsiders, and I have all the debugging information I need to fix whatever the problem is.

In short, it sounds like what you need is some detailed logging that is only accessible internally.

Answer 2

You could obscure the errors using hash/hmac. One option would to have secret key K hardcoded in app (or in a file if you are pedantic, or the app is widely distributed). On error generate random token T, then display error as HMAC(K, T + error_code);

When debugging, just use a simple utility to try all possible errors and see which one generated the HMAC. This obscures the error enough for user not to find out which error it was, but still allows not too difficult debugging.

PS: Also using non-sequential error codes may help.

Answer 3

Yes, Yes, return meaningful errors

Security is hard enough. Make the developer or user experience easier. In this case, the tradeoff is minimal.

Does returning specific internal error codes can help attackers in their penetrations attempts?

Yes, but (hopefully) not to a meaningful extent.

How can the verbose error message hurt you?

Actually none of your mitigations prevents some timing attacks. Here is a simple timing attack. Let's say you are comparing a password string to a password string like this:

$password = "bobcat"

The way the computer checks this is:

for char1 in $password: for char2 in "bobcat": if char1 != char2: break

Now, if i send the password "p", and it fails slower than if I send the password "a", I'll know the first character is "p".

Now I just need to loop through the rest of the alphabet until I get the rest of the characters.

If your errors are timing attack resilient, don't worry about the verbosity.