{"id":694,"date":"2017-11-30T14:31:50","date_gmt":"2017-11-30T14:31:50","guid":{"rendered":"https:\/\/securitycurve.com\/?p=694"},"modified":"2017-11-30T14:31:50","modified_gmt":"2017-11-30T14:31:50","slug":"why-the-macos-password-thing-is-so-scary","status":"publish","type":"post","link":"https:\/\/securitycurve.com\/?p=694","title":{"rendered":"Why the MacOS password thing is so scary"},"content":{"rendered":"<p><img decoding=\"async\" class=\"alignright size-large lazyload\" data-src=\"https:\/\/i.giphy.com\/media\/ZBTDRmBXNhF3W\/giphy.webp\" width=\"300\" height=\"233\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" style=\"--smush-placeholder-width: 300px; --smush-placeholder-aspect-ratio: 300\/233;\" \/>You maybe heard about the MacOS root password issue (i.e. #IAmRoot)? If you haven&#8217;t heard about it and you&#8217;re reading this on a Mac running High Sierra, <a href=\"https:\/\/support.apple.com\/en-us\/HT208315\">go patch<\/a>.\u00a0 Seriously.\u00a0 Go do it now (we&#8217;ll wait) &#8212; and also maybe <a href=\"https:\/\/support.apple.com\/en-us\/HT208317\">bookmark this link<\/a> in case you run into trouble with file sharing on the other side.<\/p>\n<p>If you haven&#8217;t heard of it or you&#8217;re reading this on something other than High Sierra, you might want to check out the deep dive coverage of the<a href=\"https:\/\/www.theregister.co.uk\/2017\/11\/29\/apple_macos_high_sierra_root_bug_patch\/\"> issue via The Register<\/a>.\u00a0 They go down to the source code level to outline exactly what went wrong and why.\u00a0 It makes for interesting reading and I promise you don&#8217;t need to have a working knowledge of C to follow along with the explanation (although it does help if you want to unpack the <a href=\"https:\/\/regmedia.co.uk\/2017\/11\/29\/macos_bug_screen.png\">nitty gritty<\/a>&#8230; which, by the way, would be a heck of a lot easier to read I&#8217;m sure if we had access to the constant declarations and variable names.\u00a0 But we don&#8217;t, so think of it as a refresher for your C skills.)<\/p>\n<p>This bug is really, really scary to me.\u00a0 No, not because it sets the root password to a blank string.\u00a0 <a href=\"https:\/\/freedom-to-tinker.com\/2013\/10\/09\/the-linux-backdoor-attempt-of-2003\/\">Linux had one back in the day (2003)<\/a> that set the uid to root (zero) in wait4 based on confusion about the assignment operator (=) vs. the comparison operator (==).\u00a0 That Linux one was potentially worse than this because it could have potentially been (Ed Felten over at Princeton says it almost certainly was) an active attempt at subterfuge rather than an innocuous coding issue like #IAmRoot seems to be.\u00a0 That&#8217;s not the scary part.\u00a0 The scary part is something else which I&#8217;ll get to that in a minute, but a quick synopsis on what #IAmRoot actually is.<\/p>\n<p>This bug essentially works this way:\u00a0 you know that root is disabled on High Sierra, right? Or at least it&#8217;s supposed to be?\u00a0 Well, since it&#8217;s disabled, it doesn&#8217;t have an entry in the password list.\u00a0 So the shadow entry (which I&#8217;ll confess I was surprised to learn this isn&#8217;t \/etc\/shadow on MacOS &#8212; you learn something new every day) doesn&#8217;t exist.\u00a0 If you try to log in with root, the system will check the password, which fails (appropriately).\u00a0 Since the shadow validation failed, the system will check to see if there&#8217;s a corresponding legacy crypt() entry.\u00a0 There isn&#8217;t of course, but the call to do that returns a non-zero value (i.e. i.e. &#8220;true&#8221;) [this is the bug part].\u00a0 The system assumes, rightly based on my interpretation of how this call is supposed to work, that this means that there is in fact a crypt() password value and that what was supplied is, in fact, the right value.\u00a0 Therefore, the system will attempt to &#8220;upgrade&#8221; the crypt() entry to a shadow password entry, copying the value (null) and creating a shadow password entry containing that value.\u00a0 After that, null&#8217;s the new root password.<\/p>\n<p>It&#8217;s not a complicated bug.\u00a0 The part the scares the crap out of me though is that it made it to production.\u00a0 No, seriously.\u00a0 If I were Apple, and had oceans of developers and testers working on my product, I&#8217;d do pre-production testing for security issues &#8211; I&#8217;d probably have pre-release testing scripts to exercise security-relevant functionality.\u00a0 You would too, right?\u00a0 Were I to do so, I&#8217;d likely automate a number of commonly-occurring security-related events that might transpire once the product is in the field.\u00a0 With me so far?\u00a0 What would one of those test cases be?\u00a0 Root login.\u00a0 Probably a bunch of other stuff too, but almost certainly root login would be included.\u00a0 It&#8217;s literally the least you can do.<\/p>\n<p>In fact, I&#8217;d probably have an automated test that tries to log in with a number of different commonly-occurring root password values in addition to a &#8220;blank&#8221; value.\u00a0 To what purpose you ask (since root should be disabled)?\u00a0 A few reasons: 1) it takes like 5 minutes to script that and you can use that same script on every single release from now until passwords go away, 2) it costs you nothing to include a test scenario to do that (it takes what like 30 seconds to execute?), and 3) developers love to put in admin-level back doors and this would help stop that.\u00a0 Here&#8217;s the real deal though: root login is supposed to be disabled, so you testing to make sure that it is is absolutely the minimum reasonable test case to ensure that functionality works.\u00a0 Could you test it some other way &#8212; like checking if the password file exists?\u00a0 You could, but that doesn&#8217;t exercise the functionality.\u00a0 Not exercising the functionality is &#8220;pants-soilingly&#8221; scary.<\/p>\n<p>This is code that changes from time to time.\u00a0 You know every time that Apple introduces some new logon mechanism &#8211; like fingerprint or facial recognition?\u00a0 That has the potential to change this code.\u00a0 It might not change it every time, but my point is that this code has developers in it from time to time.\u00a0 Say, for example, one of those developers accidentally does the same thing the Linux backdoor did in 2003.<\/p>\n<p>For example, they change a line like this one (tweaked to make my point):<\/p>\n<pre>int result = verify_password(var70, rax, var60, &amp;var54, $var41);\nif ( result == 1) { logon(); }<\/pre>\n<p>to<\/p>\n<pre>int result = verify_password(var70, rax, var60, &amp;var54, $var41);\nif (result = 1) { logon(); }<\/pre>\n<p>See the difference?\u00a0 You might not notice that in a sea of surrounding code, right?\u00a0 Yeah, me neither.\u00a0 And I say that as a person\u00a0who was, at one point, wicked good at that (team members once called me the &#8220;human lint&#8221; &#8212; as in the validation tool not the fabric residue).<\/p>\n<p>The point is, you need to be checking this stuff.\u00a0 Since Apple didn&#8217;t catch this bug, I can only conclude that they didn&#8217;t have this test case in place.\u00a0 Since this is absolutely the most fundamental and trivial test case that you&#8217;d possibly conceive of, I can only conclude that they are doing no security functional testing at all.\u00a0 As in zero, nada, zip, the null set.\u00a0 That is really, really not a good sign &#8211; particularly for a product like this one that has such a large user base and is marketed as a &#8220;more secure alternative&#8221; to other platforms.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>You maybe heard about the MacOS root password issue (i.e. #IAmRoot)? If you haven&#8217;t heard about it and you&#8217;re reading this on a Mac running High Sierra, go patch.\u00a0 Seriously.\u00a0 Go do it now (we&#8217;ll wait) &#8212; and also maybe bookmark this link in case you run into trouble with file sharing on the other [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[4],"tags":[9,75,105],"class_list":["post-694","post","type-post","status-publish","format-standard","hentry","category-security","tag-apple","tag-macos","tag-sdlc"],"_links":{"self":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts\/694","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=694"}],"version-history":[{"count":0,"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts\/694\/revisions"}],"wp:attachment":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=694"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=694"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=694"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}