{"id":789,"date":"2019-04-25T19:41:29","date_gmt":"2019-04-25T19:41:29","guid":{"rendered":"http:\/\/www.smart-bricks.net\/?p=789"},"modified":"2019-04-28T22:23:11","modified_gmt":"2019-04-28T22:23:11","slug":"google-researchers-say-spectre-will-haunt-us-for-years","status":"publish","type":"post","link":"http:\/\/www.smart-bricks.net\/index.php\/2019\/04\/25\/google-researchers-say-spectre-will-haunt-us-for-years\/","title":{"rendered":"Google Researchers Say Spectre Will Haunt Us for Years"},"content":{"rendered":"\n

According to a paper by several Google researchers, speculative vulnerabilities currently defeat all programming-language-level means of enforcing information confidentiality<\/a>.\n This would not be just an incidental property of how we build our \nsystems, but rather the result of wrong mental models that led us to \ntrade security for performance without knowing it.<\/p>\n\n\n\n

Our paper shows these leaks are not only design flaws, but are in \nfact foundational, at the very base of theoretical computation.<\/p><\/blockquote>\n\n\n\n

Information confidentiality is a highly desirable property of a \nsystem that should be enforced at different levels of abstractions, from\n the hardware up to the programming language.<\/p>\n\n\n\n

Programming languages provide a varying number of provisions to \nguarantee confidential information is not leaked. For example, in many \nmainstream languages, the type system is designed to rule out a number \nof dangerous behaviours which could put at risk integrity, \nconfidentiality, and availability. One of the most significant \nproperties type systems attempt to enforce is memory-safety, often the culprit behind many vulnerabilities<\/a>,\n and a lot of research and effort have gone into building languages in \nsuch a way they can be trusted not to do unexpected things. Spectre<\/a> has changed all that, according to Google researchers.<\/p>\n\n\n\n

Spectre allows for information to be leaked from computations that \nshould have never happened according to the architectural semantics of \nthe processor. […] This puts arbitrary in-memory data at risk, even \ndata “at rest” that is not currently involved in computations and was \npreviously considered safe from side-channel attacks.<\/p><\/blockquote>\n\n\n\n

To clarify this claim, the researchers defined a formal model of \nmicro-architectural side-channels used to define an association between a\n processor’s architectural states, i.e. the view of the processor that \nis visible to a program, and its micro-states, the CPU’s internal states\n below the abstraction exposed to programming languages. This \nassociation shows how many correct micro-states may map to a single \narchitectural state.<\/p>\n\n\n\n

For example, when a CPU uses a cache or a branch predictor, the \ntimings associated with a given operation will vary depending on the CPU\n micro-state, e.g., the data may be already available in the cache or \nneeding to be fetched from memory, but all possible micro-states will \ncorrespond to the same architectural state, e.g. use a piece of \ninformation. Furthermore, the researchers define a technique to amplify \ntiming differences and make them easily detectable, which becomes the \nbase for the construction of a universal “read gadget”, a sort of \n“out-of-bounds memory reader” giving access to all addressable memory.<\/p>\n\n\n\n

According to the researchers, such a universal read gadget may be \nbuilt for any programming language \u2013even if it is not necessarily a \ntrivial task\u2013 leveraging a number of language constructs or features \nthat they have shown to be vulnerable using their model. Those include \nindexed data structures with dynamic bounds checks; variadic arguments; \ndispatch loops; call stack; switch statements, and more.<\/p>\n\n\n\n

As a conclusion, the community is facing three major challenges: \ndiscovering micro-architectural side-channels; understanding how \nprograms can manipulate micro-states; and how to mitigate those \nvulnerabilities.<\/p>\n\n\n\n

Mitigating vulnerabilities is perhaps the most challenging of all, \nsince efficient software mitigations needed for extant hardware seem to \nbe in their infancy, and hardware mitigation for future designs is a \ncompletely open design problem.<\/p><\/blockquote>\n\n\n\n

While not reassuring, the paper does make for a quite dense read that\n is full of insights into how our mental computation model diverges from\n real computations happening in CPUs.<\/p>\n","protected":false},"excerpt":{"rendered":"

According to a paper by several Google researchers, speculative vulnerabilities currently defeat all programming-language-level means of enforcing information confidentiality. This would not be just an incidental property of how we build our systems, but rather the result of wrong mental models that led us to trade security for performance without knowing it. Our paper shows… Read More »Google Researchers Say Spectre Will Haunt Us for Years<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":70,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[1],"tags":[26,18],"class_list":["post-789","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-google","tag-security"],"_links":{"self":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts\/789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/comments?post=789"}],"version-history":[{"count":1,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts\/789\/revisions"}],"predecessor-version":[{"id":790,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts\/789\/revisions\/790"}],"wp:attachment":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/media?parent=789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/categories?post=789"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/tags?post=789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}