4

In the past there have been concerns about using ASAN in production in certain environments: https://seclists.org/oss-sec/2016/q1/363 . The comment is from 2016 - what is the landscape like today?

Is it recommendable to use the sanitizers here in a production system running on a user's device? The application receives untrusted input from other parties and processes these in various ways.

Are there security relevant impacts from using them? Do any of the added instrumentations actually make it easier to remotely exploit a bug?

The application I'm considering this for is open source, so easing reverse engineering would not be an issue for in this case.

ambiso
  • 559
  • 3
  • 10
  • Production as in production environment? – kiner_shah Nov 17 '21 at 11:39
  • Is it intended that a customer see your program crashing with error messages generated by the sanatizer code? In good old times people write tons of unit tests ... Maybe it may be an idea to have special customers with field support to provide some beta testing... – Klaus Nov 17 '21 at 11:40
  • `or would that actually cause harm?` Is not possible to answer. Imagine you have a car-self-driving application thoroughly tested without sanitizer. It "works". Then you compile that application with sanitizer and ship in your cars, and there is a bug in that program (but compiler generates sane code, so it was undetected), so sanitizer terminates the car-self-driving program, which cases the car to uncontrollably... – KamilCuk Nov 17 '21 at 11:46
  • 1
    As far as I understand, using these libraries will cause the compiler to emit more expansive metadata, so your app could get easier to hack or reverse engineer with this enabled. – 500 - Internal Server Error Nov 17 '21 at 11:46
  • @KamilCuk If there is no fallback to handle the case of the crash of the driving program, then the architecture is not ready for production. There's a good chance that crashing would be safer than other things that UB could cause instead such as full acceleration etc. – eerorika Nov 17 '21 at 12:02
  • 2
    @kiner_shah yes - production as in production environemtn – ambiso Nov 17 '21 at 12:10
  • @Klaus in this case I prefer crashing over exploitable software when possible – ambiso Nov 17 '21 at 12:10
  • 2
    @KamilCuk I see how "more safe" is actually ambiguous in my question - in my case crashing the software is safer than letting an adversary run free with e.g. a user-after-free – ambiso Nov 17 '21 at 12:12
  • @500-InternalServerError that's an interesting point, in my case the source code is public so this wouldn't be an issue – ambiso Nov 17 '21 at 12:14
  • I've updated the question to integrate the feedback in the comments I've received so far. – ambiso Nov 17 '21 at 12:18
  • I found an entry on seclists reporting issues with running ASAN in production, but I'm not yet sure if these apply in my case https://seclists.org/oss-sec/2016/q1/363 – ambiso Nov 17 '21 at 12:24
  • @KamilCuk We don't have to imagine as something similar happened with Ariane 5 - the first rocked launched exploded because some unimportant variable was out of bounds shutting down the system, and ironically ignoring it would have been fine. – Hans Olsson Nov 17 '21 at 13:18

1 Answers1

6

Sanitizers are primarily meant to be used as debug, not hardening tools i.e. for error detection at verification stage but not error prevention in production. Otherwise they may leak sensitive info to the attacker (by printing details about address space and library version to stderr on error) or obtain local root privileges due to uncontrolled use of environment variables. Also sanitizers may add quite a bit of overhead (2x slowdowns are not uncommon for Asan, 1.5x for UBsan).

In general sanitizers are sometimes used in production environment for A/B testing, to increase coverage and detect bugs which escaped normal QA.

Clang has many options for hardening: fortification (-D_FORTIFY_SOURCE=2), ASLR (-fPIE), stack protection (-fstack-protector, -fsanitize=safe-stack) and control-flow integrity (-fsanitize=cfi) (see Clang Hardening Cheatsheet for details). They have a much smaller overhead and are specifically meant to be used in production.

UPDATE (thanks to @cisnjxqu):

UBsan supports the -fsanitize-minimal-runtime mode which provides minimalistic, low-overhead runtime library which is supposed to not increase the application attack surface.

yugr
  • 19,769
  • 3
  • 51
  • 96
  • Thanks for your comments - I've just updated the questions with some more details, could you maybe reflect on these too? – ambiso Nov 17 '21 at 12:29
  • 1
    The link in your answer appears to be broken but I think it's the [same one that I found](https://seclists.org/oss-sec/2016/q1/363). I think you meant to link to [here](https://www.openwall.com/lists/oss-security/2016/02/17/9)? There's an extra zero at the end of your link. – ambiso Nov 17 '21 at 12:29
  • Also that mail is from 2016 - are there any relevant changes since then? – ambiso Nov 17 '21 at 12:30
  • @cisnjxqu interesting, I was not aware of the modified UBsan runtime which you mentioned in your question. AFAIK there were no major changes to Asan since then except for HW-assisted Asan on AArch64. – yugr Nov 17 '21 at 12:47
  • Uhh the Clang Hardening Cheatsheet looks nice, thanks – ambiso Nov 17 '21 at 13:09
  • The minimal runtime also looks very interesting! – ambiso Nov 17 '21 at 13:13