Fixed inter-blog links.

_posts/2007-01-03-towards-verifiable-operating-systems.html

@@ -9,4 +9,4 @@
 blogger_orig_url: http://theinvisiblethings.blogspot.com/2007/01/towards-verifiable-operating-systems.html
 ---
 
-Last week I gave a presentation at the <a href="http://events.ccc.de/congress/2006/Home">23rd Chaos Communication Congress</a> in Berlin. Originally the presentation was supposed to be titled "Stealth malware - can good guys win?", but in the very last moment I decided to redesign it completely and gave it a new title: "Fighting Stealth Malware – Towards Verifiable OSes". You can download it from  <a href="http://invisiblethings.org/papers/towards_verifiable_systems.ppt">here</a>.<br /><br />The presentation first debunks The 4 Myths About Stealth Malware Fighting that surprisingly many people believe in. Then <a href="http://theinvisiblethings.blogspot.com/2006/11/introducing-stealth-malware-taxonomy.html">my stealth malware classification</a> is briefly described, presenting the malware of type 0, I and II and challenges with their detection (mainly with type II). Finally I talk about what changes into the OS design are needed to make our systems <span style="font-style:italic;">verifiable</span>. If the OS were designed in such a way, then detection of type I and type II malware would be a trivial task...<br /><br />There are only four requirements that an OS must satisfy to become easily verifiable, these are:<br /><ol><li> The underlying processors must support non-executable attribute on a per-page level,</li><br /><li>OS design must maintain strong code and data separation on a per-page level (this could be first only in kernel and later might be extended to include sensitive applications),</li><br /><li>All code sections should be verifiable on a per-page level (usually this means some signing or hashing scheme implemented),</li><br /><li>OS must allow to safely read physical memory by a 3rd party application (kernel driver/module) and for each page allow for reliable determination whether it is executable or not.</li></ol><br />The first three requirements are becoming more and more popular these days in various operating systems, as a side effect of introducing anti-exploitation/anti-malware technologies (which is a good thing, BTW). However, the 4th requirement presents a big challenge and it is not clear now whether it would be feasible on some architectures.<br /><br />Still, I think that it's possible to redesign our systems in order to make them verifiable. If we don't do that, then we will always have to rely on a bunch of "hacks" to check for some <span style="font-style:italic;">known</span> rootktis and we will be taking part in endless arm race with the bad guys. On the other hand, such situation is very convenient for the security vendors, as they can always improve their "Advanced Rootkit Detection Technology" and sell some updates... ;)<br /><br />Happy New Year!
+Last week I gave a presentation at the <a href="http://events.ccc.de/congress/2006/Home">23rd Chaos Communication Congress</a> in Berlin. Originally the presentation was supposed to be titled "Stealth malware - can good guys win?", but in the very last moment I decided to redesign it completely and gave it a new title: "Fighting Stealth Malware – Towards Verifiable OSes". You can download it from  <a href="http://invisiblethings.org/papers/towards_verifiable_systems.ppt">here</a>.<br /><br />The presentation first debunks The 4 Myths About Stealth Malware Fighting that surprisingly many people believe in. Then <a href="/2006/11/24/introducing-stealth-malware-taxonomy.html">my stealth malware classification</a> is briefly described, presenting the malware of type 0, I and II and challenges with their detection (mainly with type II). Finally I talk about what changes into the OS design are needed to make our systems <span style="font-style:italic;">verifiable</span>. If the OS were designed in such a way, then detection of type I and type II malware would be a trivial task...<br /><br />There are only four requirements that an OS must satisfy to become easily verifiable, these are:<br /><ol><li> The underlying processors must support non-executable attribute on a per-page level,</li><br /><li>OS design must maintain strong code and data separation on a per-page level (this could be first only in kernel and later might be extended to include sensitive applications),</li><br /><li>All code sections should be verifiable on a per-page level (usually this means some signing or hashing scheme implemented),</li><br /><li>OS must allow to safely read physical memory by a 3rd party application (kernel driver/module) and for each page allow for reliable determination whether it is executable or not.</li></ol><br />The first three requirements are becoming more and more popular these days in various operating systems, as a side effect of introducing anti-exploitation/anti-malware technologies (which is a good thing, BTW). However, the 4th requirement presents a big challenge and it is not clear now whether it would be feasible on some architectures.<br /><br />Still, I think that it's possible to redesign our systems in order to make them verifiable. If we don't do that, then we will always have to rely on a bunch of "hacks" to check for some <span style="font-style:italic;">known</span> rootktis and we will be taking part in endless arm race with the bad guys. On the other hand, such situation is very convenient for the security vendors, as they can always improve their "Advanced Rootkit Detection Technology" and sell some updates... ;)<br /><br />Happy New Year!

_posts/2007-02-12-vista-security-model-big-joke.html

@@ -9,4 +9,4 @@
 blogger_orig_url: http://theinvisiblethings.blogspot.com/2007/02/vista-security-model-big-joke.html
 ---
 
-[<b>Update:</b> if you came here from ZDNet or Slashdot - see <a href="http://theinvisiblethings.blogspot.com/2007/02/confiusion-about-joke.html">the post about confusion</a> above!]<br /><br />Today I saw a <a href="http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx">new post at Mark Russinovich’s blog</a> which I take as a response to my <a href="http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html">recent musings</a> about Vista security features, where I pointed out several problems with UAC, like e.g. the attack that allows for a low integrity process to hijack the high integrity level command prompt. Those who read the whole article undoubtedly noticed that my overall opinion of vista security changes was still very positive – after all everybody can do mistakes and the fact UAC is not perfect, doesn’t diminish the fact that it’s a step into the right direction, i.e. implementing least-privilege policy in Windows OS. <br /><br />However, I now read this post by Mark Russinovich (a Microsoft employee), which says:<br /><blockquote>"It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard. Further, as Jim Allchin pointed out in his blog post Security Features vs Convenience, Vista makes tradeoffs between security and convenience, and both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use."</blockquote><br />And then we read:<br /><blockquote>"Because elevations and ILs don’t define a security boundary, potential avenues of attack, regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption."</blockquote><br />Oh, excuse me, is this supposed be a joke? We all remember all those Microsoft’s statements about how serious Microsoft is about security in Vista and how all those new cool security features like UAC or Protected Mode IE will improve the world’s security. And now we hear what? That this flagship security technology (UAC) is in fact… not a security technology!<br /><br />I understand that implementing UAC, UIPI and Integrity Levels mechanisms on top of the existing Windows OS infrastructure is a hard task and it would be much easier to design the whole new OS from scratch and that Microsoft can’t do this for various of reasons. I understand that all, but that doesn’t mean that once more people at Microsoft realized that too, they should turn everything into a big joke? Or maybe I’m too much of an idealist… <br /><br />So, I will say this: If Microsoft won’t change their attitude soon, then in a couple of months the security of Vista (from the typical malware’s point of view) will be equal to the security of current XP systems (which means, not too impressive).
+[<b>Update:</b> if you came here from ZDNet or Slashdot - see <a href="/2007/02/13/confiusion-about-joke.html">the post about confusion</a> above!]<br /><br />Today I saw a <a href="http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx">new post at Mark Russinovich’s blog</a> which I take as a response to my <a href="/2007/02/04/running-vista-every-day.html">recent musings</a> about Vista security features, where I pointed out several problems with UAC, like e.g. the attack that allows for a low integrity process to hijack the high integrity level command prompt. Those who read the whole article undoubtedly noticed that my overall opinion of vista security changes was still very positive – after all everybody can do mistakes and the fact UAC is not perfect, doesn’t diminish the fact that it’s a step into the right direction, i.e. implementing least-privilege policy in Windows OS. <br /><br />However, I now read this post by Mark Russinovich (a Microsoft employee), which says:<br /><blockquote>"It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard. Further, as Jim Allchin pointed out in his blog post Security Features vs Convenience, Vista makes tradeoffs between security and convenience, and both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use."</blockquote><br />And then we read:<br /><blockquote>"Because elevations and ILs don’t define a security boundary, potential avenues of attack, regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption."</blockquote><br />Oh, excuse me, is this supposed be a joke? We all remember all those Microsoft’s statements about how serious Microsoft is about security in Vista and how all those new cool security features like UAC or Protected Mode IE will improve the world’s security. And now we hear what? That this flagship security technology (UAC) is in fact… not a security technology!<br /><br />I understand that implementing UAC, UIPI and Integrity Levels mechanisms on top of the existing Windows OS infrastructure is a hard task and it would be much easier to design the whole new OS from scratch and that Microsoft can’t do this for various of reasons. I understand that all, but that doesn’t mean that once more people at Microsoft realized that too, they should turn everything into a big joke? Or maybe I’m too much of an idealist… <br /><br />So, I will say this: If Microsoft won’t change their attitude soon, then in a couple of months the security of Vista (from the typical malware’s point of view) will be equal to the security of current XP systems (which means, not too impressive).

_posts/2007-02-13-confiusion-about-joke.html

@@ -9,4 +9,4 @@
 blogger_orig_url: http://theinvisiblethings.blogspot.com/2007/02/confiusion-about-joke.html
 ---
 
-It seems that <a href="http://it.slashdot.org/it/07/02/13/1922237.shtml">many people</a> didn’t fully understand why I wrote the previous post – <a href="http://theinvisiblethings.blogspot.com/2007/02/vista-security-model-big-joke.html">Vista Security Model – A Big Joke</a>... There are two things which should be distinguished:<br /><br />1) The fact that UAC <b>design</b> assumes that every setup executable should be run elevated (and that a user doesn't really have a <b>choice</b> to run it from a non-elevated account),<br /><br />2) The fact that UAC <b>implementation</b> contains bug(s), like e.g. the bug I pointed out in my <a href="http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html">article</a>, which allows a low integrity level process to send WM_KEYDOWN messages to a command prompt window running at high integrity level.<br /><br />I was pissed off not because of #1, but because Microsoft employee - Mark Russinovich - <a href="http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx">declared  </a> that all <b>implementation</b> bugs in UAC are not to be considered as security bugs.<br /><br />True, I also don't like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but I can understand such a design decision (as being a compromise between usability and security) and this was <b>not</b> the reason why I wrote "The Joke Post".
+It seems that <a href="http://it.slashdot.org/it/07/02/13/1922237.shtml">many people</a> didn’t fully understand why I wrote the previous post – <a href="/2007/02/12/vista-security-model-big-joke.html">Vista Security Model – A Big Joke</a>... There are two things which should be distinguished:<br /><br />1) The fact that UAC <b>design</b> assumes that every setup executable should be run elevated (and that a user doesn't really have a <b>choice</b> to run it from a non-elevated account),<br /><br />2) The fact that UAC <b>implementation</b> contains bug(s), like e.g. the bug I pointed out in my <a href="/2007/02/04/running-vista-every-day.html">article</a>, which allows a low integrity level process to send WM_KEYDOWN messages to a command prompt window running at high integrity level.<br /><br />I was pissed off not because of #1, but because Microsoft employee - Mark Russinovich - <a href="http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx">declared  </a> that all <b>implementation</b> bugs in UAC are not to be considered as security bugs.<br /><br />True, I also don't like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but I can understand such a design decision (as being a compromise between usability and security) and this was <b>not</b> the reason why I wrote "The Joke Post".