Hack the Gibson #81 to #87

Read the reason for these posts. Read Steve Gibson's response.

Here is again a long overdue post about the recent Security Now episodes. I have to say that the quality of the information provided in the recent episodes deteriorated (or maybe it is that they started talking about more concrete things where the errors are also more concrete).

First of all a word about Steve Gibson's magic tool Spinrite: in all the episodes I've heard Steve and Leo never mentioned once the fact that failing harddrives should be replaced after successful recovery. To be fair I've heard from other sources that they were occasions where they made such recommendations, however I never personally heard such a thing. In my opinion it is irresponsible to let people using failing hardware which puts their data in continuous jeopardy and not giving them the proper advice: back up, get a new hard drive and throw away the old one (after securely wiping it with something like dban). Then again I don't know what some people are doing with their hardware, since in the 15 years I've been using computers (knock on wood) not once had I a HD die on me or any of the people I know personally. Now back to our regular schedule :).

Episode #81 was pretty uneventful if you don't consider the few times here and there where Spinrite was pushed, of which I disapprove not because I think that it is a bad product (given that I can't test it since there is no demo / trial version available) or because I think that podcasts should be commercial free, but because in my humble opinion they fail to mention the disclaimer regularly enough: if you have a failing drive and by some wonder you manage to get it working make a backup and get a new hard drive! If you want to hear an informative podcast about data recovery, I would recommend this episode of Cyberspeak instead.

Episode #84 also has some Spinrite praising at the beginning, this time a corporate server was resurrected allegedly, which is cool, however there is again no mention of replacing the failing hard drive. A company which wouldn't cough up the money for a new hard drive for the server when the old one is dying... I really have no words for it. Also immediately following it there are Leo's comments on how he is recording to a drive fixed by Spinrite.

The first omission comes from the guy asking about moving his SSH server to a non-standard port as a security measure. While moving ports is a very good addition to security (and I recently recommended it), however there is also an other very good security measure: firewalls. Does really everybody in the world need access to your SSH server? Restrict its availability as much as possible. Ideally you would restrict it to a couple of IP addresses, but even if you have larger needs, at least restrict it to some (even if large) subsets of IP (you can do this with the built-in firewall starting from Windows XP). There is really no need for the Chinese government to be accessing your servers.

Getting to the Javascript question: the original name of Javascript was Livescript and it got the name Javascript as a marketing gimmick. If you want to lear about Javascript from the masters, wisit the YUI (Yahoo! User Interface) theater and wath the videos of Douglas Crockford. They are gold. Getting back to the supposed problems of client side scripting: many problems (both security and usability) are not created by Javascript and because of this they don't go away magically when you disable it. It is possible to build sites which are usable without scripting enabled by subscribing to the design principles of progressive enhancement and Hijax (in fact it is very advised to do so to support alternative platforms like screen readers or mobile browsers). Also it is possible to perform many attacks (like reprogramming your router) without Javascript. You simply have to include a hidden image / iframe tag in the page which results in the corresponding request being sent to the router. Turning off javascript is security much in the sense as using Linux is - because it represents a very small percentage of the market, there are few attacks directed at it. While security by obscurity is not necessarily a bad thing, one should consider its deficiencies and not rely on it exclusively. Also, the web originally was meant to be a read/write medium (contrary to Steve's comments) and only because of technological restrictions got to be read-only for the beginning. Also, Javascript is as sandboxed (if not even more) as Java and Google mail runs both Java and Javascript - Java as a back-end solution with their GWT and Javascript as a front-end solution. Again, many of the problems is not caused by Javascript and would still be exploitable if it hadn't been for it.

Episode #85

The first error is near the beginning :), where Steve's says:

That is, you know, any time you’ve got current running through a wire, you generate a magnetic field around the wire. And when the frequencies are high enough, that ends up generating radio frequency emissions, which of course travel much greater distances than magnetic emissions.

The correct statement is: current running through a wire generates an electro-magnetic fields, which, when it has a high enough frequency (like in a radio-frequency band) can travel pretty far (both the electric and magnetic components - which actually are perpendicular to one another). Highschool physics in Romania.

Also the podcast doesn't do a very good job of explaining what SQL is and what is the realtion between SQL (the language) and RDBMS products like MySQL or MS SQL. In short: SQL is a language (in fact an ANSI standard) and products like MySQL, Postgres, MS SQL, Oracle and others are data base server which use the relational model to store data and data about data (meta-data) - hence their collective name - RDBMS or Relational Data Base Management Systems and SQL as the language for manipulating it.

From here on this show goes downwards with statements like Jikto requires a Nikto server to run (it does not). You are better off watching the entire video for yourself. It is very informative and somewhat scary but the press (and this podcast) certainly managed to overhype it. They also manage to mis-identify the problem. The problem is not that there is no separation between textual displayed content and executed scripting content. The problem is that the security model of the browsers (and you can't blame Microsoft or Mozilla here, because the problem is in the original standard) has some loopholes. The good news is that now that they get to light, they will be fixed (although slowly).

Episode #86

Steve can't figure out what Blink is: It sounds like it’s an antivirus. It sounds like it’s antispyware. It also sounds like it does some Internet security. It sounds like it would be a very good choice for a lot of people. This is surprising for someone who explained ASLR (Address Space Layout Randomizatio). Blink basically brings ASLR and some similar technologies to Windows (which btw. are since long available on other operating systems) to prevent exploits from running and it does it very well both because there are some very smart people working on it and because it has a small market share not specifically targeted by exploit authors. This is a very important pillar of malware protection: if you can get your environment sufficiently different from the average users environment (for example installing Windows in different directories, running as limited user, etc), you are protected from 95% of the malware out there which target high numbers and don't make any efforts to dynamically adjust to different or more restrictive environments. This could (and probably will) change as such methods become more and more widely used, the idea is to stay ahead of the curve (and remembering that security is not a point in time, it is a process).

Also the statement IE7 with its enhanced protection turned on was not vulnerable to this is incorrect. IE7 was vulnerable to it, the only thing the exploit couldn't do was to write files (to install it or some of its components permanently), however it could read files and communicate their contents back to the server.

While there are some good remarks in the podcast, like As I’ve said before, as a developer myself, the psychology of the developer is, oh, can I just get this thing working? I just want to be done with this. I want to get this working because my boss is breathing down my neck, and I’m already three weeks late. And so there isn’t that awareness., it is confusing, lacking in details and provides no real solution. If you want a more accurate description of the problem without all the FUD (Fear, Uncertainty and Doubt), go listen to this podcast.

Episode #87

First an update about the protected processes: a clever guy (originally from Romania :)) already figured out how to remove the protection.

The rest of the podcast tries to discuss SQL injections, but falls in the same (hopefully unintentional) trap as the previous one: makes some mistakes which could confuse beginner listeners, overstates the possibilities and gives no defensive solutions. I would recommend reading my previous post, not because I'm so much smarter, but because I tried to focus on these issues and at the end of it there are links to people more knowledgeable in these matters.

The end (momentarily).