<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/61826>61826</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [Umbrella] Enabling taint analysis by default.
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang:static analyzer
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            haoNoQ
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          haoNoQ
      </td>
    </tr>
</table>

<pre>
    Let's collect the remaining blockers for taint analysis here – false positives, UI issues, but not false negatives / feature requests. We can extract them into sub-issues later if we find that valuable.

First, there's a problem that affects all checkers:
* Taint propagation isn't properly explained in the notes. https://reviews.llvm.org/D144269 is trying to address that.
  * It's likely that value tracking needs to be added on top of that (not just explain where tainted symbol was obtained, but how it got assigned to the variable we're reading it from).

Now, we have 5 taint-aware checks: 2 already enabled by default (but will gain taint awareness when taint analysis is enabled) - the division by zero checker and the VLA checker; 3 will be enabled together with taint analysis (various checks that are currently all clumped up in `alpha.security.taint`). We need to either make sure all 5 work correctly, or separate the ones that don't so that we could keep them in alpha until they're fixed.

* _"Division by a tainted value, possibly zero"_ - The division by zero checker seems fine. That's our ideal scenario: the checker easily confirms that the value wasn't checked for zero before dereference; if it wasn't, then there's a clear path towards undefined behavior in the program.

* _"Declared variable-length array has tainted size"_ - I'm seeing two problems:
  * The checker doesn't try to confirm that the value is indeed unconstrained. I.e., this is clearly a false positive: https://godbolt.org/z/Md5z6zGhx
  * It's quite unclear whether it's actually a security concern that VLA size is tainted. [CERT ARR32-C](https://wiki.sei.cmu.edu/confluence/x/AdcxBQ) quotes a paper describing an exploit when the size is negative, but not much about the positive case.
    * In other words, at least on some platforms inability to allocate VLA will be a hard crash, so still very bad and we still need to warn, but hard to exploit.
  * How do we determine which sizes does the developer need to reject? Does Clang or LLVM already know anything about that?
  * Of course there's also a concern of allocation size being unexpected (eg., due to an integer overflow in arithmetic that determines it), but additional analysis is required to confirm this in every case.
  * Of course there's also a concern that the allocation size may not actually correspond to the amount of data written into the array (say, the data could be read from user separately a-la Heartbleed), but this, again, requires separate analysis to confirm.

* _"Guarantee that storage for strings has sufficient space"_ - Same problem as the VLA checker, but worse, because failed allocations are handled gracefully and therefore aren't an issue.
  * So it's generally not an issue at all, that untrusted data is used in these size parameters.
    * Like, say you open a file from disc or a buffer of raw data from the network, it's perfectly normal to allocate a buffer an memory same size as this file.
    * There's also nothing wrong with `memcpy`-ing that buffer to another location.
    * Just like in VLA case it could be a problem if we're using the wrong size or doing arithmetic carelessly, but it requires separate analysis to prove.
      * But in this case, unlike the VLA case, if we find no easy way to build these auxiliary analyses, it's probably better to keep the checker in alpha until we figure it out.
  * This check also doesn't check that the value is unconstrained.

* _"Untrusted data is passed to a system call"_ - The checker is alright except it seems to be too aggressive with its list of "sensitive" functions:
  * Injections into `system()` are indeed terrifying. But is the same true about `exec..()` or `dlopen()`? Isn't the whole point of these functions to be able to execute arbitrary code, as otherwise people would simply prefer static linking?
    * [CERT STR02-C](https://wiki.sei.cmu.edu/confluence/x/GdcxBQ) does mention `exec..()` but describes a completely different problem with it: it's the *arguments* of the process that are the problem, not the path to the binary. Maybe we should check for that. But then, again, it depends on which arguments the process expects to see, so we may be in no position to judge that.
  * Note that this is also a checker that checks for tainted *buffers* of data, as opposed to individual tainted *integers*. There may be infrastructure issues around them.
    * In particular, how does a user notify the analyzer that the string is sufficiently sanitized?

* _"Untrusted data is used as a format string"_ - The check appears to work correctly.
  * But I suspect that people should be using `-Wformat-nonliteral` instead, anyway, which is much more powerful and still easy to satisfy.
  * This is also a check that checks buffers rather than integers, so concerns from the `system()` checker apply here as well.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJykWM1y5DavfRp5g3JXWz3usRdeeMZx4luT3MrESZYpSIRajClS4Y9l-elvAaTUbs_UzVf1beZHLZHAwcHBITEEfbBEN9Xlp6que3S_uF-ruq4u784wxd75m_zsrHFqvvlCsao_BmidMdRGiD2BpwG11fYAjXHtE_kAnfMQUdsIaNHMQQfoyRNUP9TV1ba63kGHJhCMLuionylU9Wf4_QF0CCn_p0kRrIvlPUsHlPegqu-hI4zJ88b_JAoxbOBPghYt0Ev0mKMaQNvoIKTmPC8KBiN50B1MBJ22CmKPEZ7RJGwMbartXbW9zX_eax8iRxE5akkYYfSuMTTkz7DrqI0B0Bhoe5Ksq135vKpv4VGyH70bkUN3FnSwVf0xPyNvZqCX0aC2pEBbAdK6SGEDfYyjLFbfV_W9p2dNU9gY8zxsnD9U9f3dxYcP9f4adIDoZwY-OkClPIUg4ZVkADiSh1wxo5_IzMekCRirJ_7aEqnAazTEy5ACZyG6EVyX36_qK67F3ynEJWqYpKBSZFIQ5qFxBiYM4JooWS1V7N0EOsLBRShkU7wXJ_yMXjP4MDHIUlFUHJGO0Hk3VPX1SV1-cROvOhH0-Exwmbc_xwk95TIwblADGl5pBrK8vIJmBkUdJiO5cFSTNgYOnEjhKa9hGcCpJ_uevDosS1X1NZxL8Eo_68CFbWZ4Je8WHgAKtwj--HK7PKt2n2CX92xojSq6AzHDYNKxf79lVV8xPC6FklkhHmeavCcbzZzpZ9IwkoI0Mo-q_RbN2OMmUJu8jvNG1q32WwaTG4WrzQUgLXsP-EQQuJ14sUuYnH-C1nlPbTQzw-08BBrRYyTJy1kqwSiXKR1c_v9E0LpkFDwRjUsXgsQDyUZt-NmcS93pF1In1WWy_lXV9d0bYHFlmHCWwxldCLoxGfSqrv-Cc3j8_-oRiIbALU8beOwxt4NLHrQiNBBasgw0M4fTWz4jDNrM0DrbaT-UjDNruXsmLP2c31eiebJvQ53zBIo8deTJtsTl1x2zevmqiIs9UZjWEHoYkcngJvQqQLKKOtGIhnp81s4vYjF6d_A4fB9Bag16AS032Lkhe4g9oPc4Q4_h2Lj6lQqID1X9cWC0RFEmtyjeUdiyoDy-AUk5KjBEPzOrClzv0eIesoqZl2zrbIheNGIDDxvaZDBymwkGzOx3E4KrcyqMB6caZ2LRxNeqvv9ZXb7uX3_sX74jf_8kHYk3F4ynPjeezj9iGxMa2XVpG06kJW9zItzKjJRIbkZuA9Xlp88_fH2E269fd_X55-ryrqqvTmOc9JPeBNKbdkgbUqmq7xkgk4QV9f1LVd_fqvbl06-sK_8kHgA8anBkbCm0XjdcDZlto3HMoMKaNZ5lNr6dmkNqe8DGpVyDBURoMdA6HAo-FlwWIeeVjF6MYAhD5CkQ3EAwGoyd4x7QFhttGB6eOMa4lkWB0Vm0DaFHr6D1GHpeLDgIkX97Jj9Dg0rkcaLydBGjCb1dBwYvwAKVMz4ZZj-5CZTj7xVF8oO2BFOv217gCMLHrM70TIYH7bqFp7-pjdXuHu74pc8G7YG17cuXP35eB8aTdROgnWMvsBcEkT97G8b_dix0PtDb_jXBcRMX3rhuAYg1SYrVSGclSy8jtdx8VX1FB6G_4nnsuM5MrgN5cM_kO8Oz0wJ6HfuBom6L7i65B2Hw9YIcKqV5OzQno4t9kvYZhWN_SksCSV1OePEfJrh2-Ps0B5yFhGtXyTQJo7Pr4MfBJRsZI4URYfI6RrLZssnvolNVfRVwLlKZ38zjpclOQTwCpEDHAcU9fG4QfiL0sTEkA3uBh3MWgvPc538UYMJxvq2wHaH6rsL-mNCjjUQZhhCdxwPJDAjRa3sIorIhdZ1uNdkIYcR2UdrfcKDVT2L4xi2UeCfnQ25rajEFgg41-4Yj4EH8QI9W8fODx5a6JEKWPYjPo4itjYg084vd8Emtf3OLDh7IkpeSSf3KyywIaEyuA0ae5D4F5q-URAcuwWJiQxEmxnNgmoZ3evNFP0lOAWeYXQI3kmW114ZyPZUOLfclQpO6jjuhA49T3kzeEK9MkZ0Kr1SCH8l34lnAOj-gOZGodTG0MNDg_AyBiyCxSgV0kBjeRft4yn7rsjBM3vGfbNuq_XagoR3nar89l8nJGJXdpKWzvC4le7fB_7CnZm_O-AkHMBA7hZXpx5OHnF2ye0ohb0UlFMnD8TwW3TrqRYueDIWQrRyzSsd_4f3o3fNbHHKgn_hTm4HiGHm5ZCXylb7l8ZszlnXso2aYUEZGk7RRhSaYXrTR6OeyeT73LcX0rkE2eQ3FmIFcPOXqPd5ZS9nywEZWR3DpdG48Stj8YS7k0bfkh9_alVOf8j0N-P2bPhgxhCyzCGEOkQZopXNWk7rGzoTy-tDzgaqlUcqSjWo-h0XnAA8HPtLx4Baq6cjHuCC6WdV1IFu8UV1Dl2wrivDOrD1YnnoiFaKu1X6bI6vqK5bG_VYkpJizSN7rjo-Um1zwrE3SKtGzFMhErPZbeqF2szku4jw_VTxy7fqUh-3D4g-Zq70z7EZ01v7MgzXy5QTKB0IZ_9QmpqZvdPTMk9Yp4RcfMrmnJs0GkdzIJ0hpl6CH0cwwivOGEJFbwGjLx9w3IzxDs_i33x6_bv8L__bj6t_EfAxkZRR-ByPuvmLqxOa1bhgNydBSupOzQlybvVScfW_pCUawqm_RHxJvEjiHjCJ_1C6Hf6lnecgrMWIs5_Iony3k34226OcN_IxzQ-LIesEwN4Tc4PQYMw_4qHIyOTVnMpJVgV1idmBrYCchZbMjxQ1ExRJO2SU0onrWFYMqtw7wd1IH-vYa4xcXaWnTbGsWP1JaSn4rR-X1_klM1m1W4wUw7taFRuPoSsdqywdIlXhwHL8sbow_3eRhcAy88xiiT63cRZVLJvQu5dE7fOuzR_RRt8mgTPherKwQQSyMdVF3c7Y_LIivS07SgWIqOOujpTA8w6yO-pXUSu5_kygZ1cibsqMX68Irv5cowHEk9FK20xuBk6IwNx4gpDDmy0CMSz8WMjXLqOLp-Gfe8tw6a3Rkp8FdoW2IhHJdhHaesuHLjNIhn2QGNjGjm8h3yYi3yacHGS1MLIw6dPO3iv-OJSccKaQAjzKfY38036HQtFjdcLQd35HP9dpnZOkRimCAiYzZnKmbnbreXeMZ3Vzsr7YXu-t9fX3W33zY1d31FV6q7eXu6qO6UPu6Vu3H_VW377aXOzrTN_W23m13u-32ov64vd5cXOKHdtc19WW7r-nquvqwpQG1We8Fz4SBN_uLq3p_ZrAhE8qdbssnnWp3W-RwIVe55PU3vMJ5kw6h-rDl8XK8azyLOhq5Gv59aDwZg9XlHfxgsTFiP05vrI6XbJuz5M3Nu-O6jn1qNq0bqvqeNyh_nY_eycGsvl9uf-8lif8LAAD__1wUvRs">