{"id":2965,"date":"2010-10-08T11:38:38","date_gmt":"2010-10-08T10:38:38","guid":{"rendered":"https:\/\/www.darknet.org.uk\/?p=2965"},"modified":"2015-09-09T19:37:26","modified_gmt":"2015-09-09T11:37:26","slug":"adobe-pdf-reader-rewrite-to-include-sandbox-feature","status":"publish","type":"post","link":"https:\/\/www.darknet.org.uk\/2010\/10\/adobe-pdf-reader-rewrite-to-include-sandbox-feature\/","title":{"rendered":"Adobe PDF Reader Rewrite To Include Sandbox Feature"},"content":{"rendered":"<p>A lot of people have complained about the lack of security in <a href=\"https:\/\/www.darknet.org.uk\/tag\/adobe\/\">Adobe<\/a> PDF related products and the fact that the very architecture is insecure. There have been a whole spate of <a href=\"https:\/\/www.darknet.org.uk\/tag\/pdf\/\">PDF<\/a> related exploits and vulnerabilities lately &#8211; some of them being very serious.<\/p>\n<p>It&#8217;s good to see Adobe is taking this matter seriously and rather than just issuing patch after patch (firefighting) they are trying to do something fundamentally different with their PDF reader software to fix the root cause.<\/p>\n<p>Now I&#8217;m not saying this will solve all the PDF related problems, but it&#8217;s good to see them doing a ground up rebuild and implementing safety features like <a href=\"https:\/\/www.darknet.org.uk\/tag\/sandbox\/\">sandboxing<\/a>.<\/p>\n<blockquote><p>Adobe has offered more details of the &#8216;sandbox&#8217; security feature it plans to implement to secure its hugely popular but often-attacked PDF Reader software. First announced last July, the latest description put out by Adobe&#8217;s security development team makes clear that Reader&#8217;s new &#8216;protected mode&#8217; will be no mere bolt-on. This is starting to look like a ground-up re-design of how the program operates, almost from scratch.<\/p>\n<p>The new Reader design will see core and risky PDF functions such as font rendering, Javascript execution, 3D rendering and image parsing happen within the confines of the application itself, isolating these from the privileges of the operating system.<\/p>\n<p>This effectively relegates Reader to a new rung of privilege below that if the system user, which stops the application simply accessing key parts of the OS such as the Registry or file system as it likes. Instead all such calls will have to go through a trusted broker process if they want to communicate beyond the sandbox. <\/p><\/blockquote>\n<p>It&#8217;s a good model though and similar to what <a href=\"https:\/\/www.darknet.org.uk\/tag\/google\/\">Google<\/a> have done with the <a href=\"https:\/\/www.darknet.org.uk\/tag\/chrome\/\">Chrome<\/a> browser.<\/p>\n<p>Separating the &#8216;dangerous&#8217; parts from the parts that have access to the underlying OS is extremely important, <a href=\"https:\/\/www.darknet.org.uk\/tag\/javascript\/\">JavaScript<\/a> execution of course being the main culprit. But other exploits have focused on font and image rendering so they need to be kept away too.<\/p>\n<script async src=\"https:\/\/pagead2.googlesyndication.com\/pagead\/js\/adsbygoogle.js?client=ca-pub-3033787195489589\"\r\n     crossorigin=\"anonymous\"><\/script>\r\n<!-- Darknet Responsive Post Ad Links [previously link ad unit] -->\r\n<ins class=\"adsbygoogle\"\r\n     style=\"display:block\"\r\n     data-ad-client=\"ca-pub-3033787195489589\"\r\n     data-ad-slot=\"5456620019\"\r\n     data-ad-format=\"auto\"><\/ins>\r\n<script>\r\n     (adsbygoogle = window.adsbygoogle || []).push({});\r\n<\/script>\n<blockquote><p>The new design won&#8217;t stop exploits targeting Reader but they will limit what can be done from within its confines. At the moment, that is more or less anything the attacker wants, including being able to take over the system.<\/p>\n<p>&#8220;The challenge is to enable sandboxing while keeping user workflows functional without turning off features users depend on,&#8221; says Adobe&#8217;s blog.<\/p>\n<p>As the developers admit, the potential hole in security is always the operating system itself, which can still be compromised, although exploiting such vulnerabilities is as easy as it easy a few years back. Microsoft&#8217;s software development lifecycle (SDL) has tightened up code security. The first version sandbox will also not protect against read access to the file system (which allows data theft) or registry, or restricting network access, but future versions will look at this aspect of security.<\/p>\n<p>Adding defence mechanism to specific applications other than browsers is an unusual approach to application design, but Reader&#8217;s security troubles have gone beyond that of most applications.<\/p><\/blockquote>\n<p>They have a pretty tough challenge on their hands as we know the more security you implement the less usability you have. So they have a precarious balance between retaining features which users require and limiting the amount of damage the software can do to the OS.<\/p>\n<p>But it&#8217;s certainly a step in the right direction and as stated above, it certainly wont prevent there being any more exploits in Adobe&#8217;s PDF Reader &#8211; but it will limit the damage any future exploits can cause.<\/p>\n<p>Source: <a href=\"http:\/\/www.networkworld.com\/news\/2010\/100710-adobe-rewrites-pdf-reader-to.html?source=nww_rss\">Network World<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A lot of people have complained about the lack of security in Adobe PDF related products and the fact that the very architecture is insecure. There have been a whole spate of PDF related exploits and vulnerabilities lately &#8211; some of them being very serious. It&#8217;s good to see Adobe is taking this matter seriously [&hellip;]<\/p>\n","protected":false},"author":25,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[12,10],"tags":[2679,3726,4731,4486,4732,4511],"featured_image_src":null,"featured_image_src_square":null,"author_info":{"display_name":"Darknet","author_link":"https:\/\/www.darknet.org.uk\/author\/darknet\/"},"_links":{"self":[{"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/posts\/2965"}],"collection":[{"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/comments?post=2965"}],"version-history":[{"count":0,"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/posts\/2965\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/media?parent=2965"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/categories?post=2965"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.darknet.org.uk\/wp-json\/wp\/v2\/tags?post=2965"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}