On Monday, September 17, 2018, Steve Dower <steve.do...@python.org> wrote:
> I investigated this thoroughly some time ago (when the MSVC flags became > available) and determined (with the help of some of the original > Spectre/Meltdown investigation team) that there is no significant value in > enabling these flags for Python. What did you fuzz with? Does that assume that e.g. Fortify has identified all bugs in CPython C? There have been a number of variants that have been disclosed; which did who test for? > > It boiled down to: > * Python allows arbitrary code execution by design Yet binaries built with GCC do have NX? Unless nested functions in C extensions? > * Pure Python code in CPython has very long per-instruction opcode > sequences that cannot easily be abused or timed A demonstration of this would be helpful. * Injected pure Python code cannot be coerced into generating native code > that is able to abuse Spectre/Meltdown but not able to abuse other attacks > more easily So, not impossible. * Code injection itself is outside of this particular threat model [Jupyter] Notebook servers are as wide open to arbitrary code execution as browser JS JITs; often with VMs and/or containers as a 'sandbox' `pip install requirements.txt` installs and executes unsigned code: Python, C extensions What can a container do to contain a speculative execution exploit intending to escape said container? I thought I read that RH has a kernel flag for userspace? > By comparison with JavaScript, most JS JITs can be easily coerced into > generating specific native code that can break sandbox guarantees (e.g. > browser tabs). Python offers none of these guarantees. This is faulty logic. Because Python does not have a JIT sandbox, speculative execution is not a factor for Python? > > Distributors are of course free to enable these flags for their own > builds, but I recommend against it for the official binaries, and would > suggest that it's worth more PR than actual security and nobody else needs > to enable it either. > > (Extension authors with significant scriptable C code need to perform > their own analysis. I'm only talking about CPython here.) Extension installers (and authors) are not likely to perform any such analysis. Extensions are composed of arbitrary C, which certainly can both directly exploit and indirectly enable remote exploitation of Spectre and Meltdown vulnerabilities. Most users of python are installing arbitrary packages (without hashes or signatures). > > Cheers, > Steve > > On 16Sep2018 0707, Wes Turner wrote: > >> Should Python builds add `-mindirect-branch=thunk >> -mindirect-branch-register` to CFLAGS? >> >> Where would this be to be added in the build scripts with which >> architectures? >> >> /QSpectre is the MSVC build flag for Spectre Variant 1: >> >> > The /Qspectre option is available in Visual Studio 2017 version 15.7 >> and later. >> >> https://docs.microsoft.com/en-us/cpp/build/reference/qspectr >> e?view=vs-2017 >> >> security@ directed me to the issue tracker / lists, >> so I'm forwarding this to python-dev and python-ideas, as well. >> >> # Forwarded message >> From: *Wes Turner* <wes.tur...@gmail.com <mailto:wes.tur...@gmail.com>> >> Date: Wednesday, September 12, 2018 >> Subject: SEC: Spectre variant 2: GCC: -mindirect-branch=thunk >> -mindirect-branch-register >> To: distutils-sig <distutils-...@python.org <mailto:distutils-sig@python. >> org>> >> >> >> Should C extensions that compile all add >> `-mindirect-branch=thunk -mindirect-branch-register` [1] to mitigate the >> risk of Spectre variant 2 (which does indeed affect user space applications >> as well as kernels)? >> >> [1] https://github.com/speed47/spectre-meltdown-checker/issues/ >> 119#issuecomment-361432244 <https://github.com/speed47/sp >> ectre-meltdown-checker/issues/119#issuecomment-361432244> >> [2] https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) < >> https://en.wikipedia.org/wiki/Spectre_%28security_vulnerability%29> >> [3] https://en.wikipedia.org/wiki/Speculative_Store_Bypass#Specu >> lative_execution_exploit_variants <https://en.wikipedia.org/wiki >> /Speculative_Store_Bypass#Speculative_execution_exploit_variants> >> >> On Wednesday, September 12, 2018, Wes Turner <wes.tur...@gmail.com >> <mailto:wes.tur...@gmail.com>> wrote: >> >> On Wednesday, September 12, 2018, Joni Orponen >> <j.orpo...@4teamwork.ch <mailto:j.orpo...@4teamwork.ch>> wrote: >> >> On Wed, Sep 12, 2018 at 8:48 PM Wes Turner >> <wes.tur...@gmail.com <mailto:wes.tur...@gmail.com>> wrote: >> >> Should C extensions that compile all add >> `-mindirect-branch=thunk -mindirect-branch-register` [1] >> to mitigate the risk of Spectre variant 2 (which does >> indeed affect user space applications as well as kernels)? >> >> >> Are those available on GCC <= 4.2.0 as per PEP 513? >> >> >> AFAIU, only >> GCC 7.3 and 8 have the retpoline (indirect-branch=thunk) support >> enabled by the `-mindirect-branch=thunk >> -mindirect-branch-register` CFLAGS. >> >> >> On Wednesday, September 12, 2018, Wes Turner <wes.tur...@gmail.com >> <mailto:wes.tur...@gmail.com>> wrote: >> >> "What is a retpoline and how does it work?" >> https://stackoverflow.com/questions/48089426/what-is-a-retpo >> line-and-how-does-it-work >> <https://stackoverflow.com/questions/48089426/what-is-a-retp >> oline-and-how-does-it-work> >> >> >> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve. >> dower%40python.org >> >> > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes. > turner%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
