?

Log in

No account? Create an account
[/.] MS Research solves the halting problem - hilarity ensues. - Adventures in Engineering — LiveJournal
The wanderings of a modern ronin.

Ben Cantrick
  Date: 2006-09-05 19:52
  Subject:   [/.] MS Research solves the halting problem - hilarity ensues.
Public
  Location:Melinda Gates' bedroom
  Mood:Laughing my nerd ass off
  Music:MC Plus+ - Alice and Bob

Researchers at Microsoft have completed work on a prototype framework called BrowserShield that promises to intercept and remove, on the fly, malicious code hidden on Web pages,

http://it.slashdot.org/it/06/09/05/0534249.shtml

Apparently those clever guys at MicroSoft have never heard of The Halting Problem. (Edit: Or Rice's Theorem.) In short, it is possible to prove mathematically (and Alan Turing did, in the 1800's) that programs like this can never both be accurate and have finite runtime. In other words, either it has bugs, or else it goes into an infinite loop. One of the two is inevitable. And we have a mathematical proof of this.

So, these guys apparently didn't even take comp sci 1001. And now MicroSoft is handing control of what code your browser will and won't execute... over to them. This is *almost* as bad an idea as allowing your browser to execute arbitrary code from random web pages in the first place! ^O^

Theoretical issues quite aside, how about practical ones?

I made a similar product once.
Unfortunately, I wrote it directly into my program without giving it another name, since I didn't realize I could sell the security separate from the program.


(Whoah, a rare /. story where the comments are worth reading!)

People just don't learn. JavaScript (and web-page embedded scripting languages in general) have been security nightmares since they were released ('96) and the passage of more than a decade has NOT improved them in any significant way. When are we going to call a spade a spade and throw JavaScript out completely?

And hell, we don't need MS to do this for us. I keep telling people, "turn off JavaScript in your browser prefs." And I've been saying this for several (going on "many") years now. When will anyone actually listen? Yeah, I know: never. Because after all, worse is better.
Post A Comment | 6 Comments | | Link






  User: nickhalfasleep
  Date: 2006-09-05 22:06 (UTC)
  Subject:   (no subject)
If it's like the runaway prevention in flash, it's pretty simple, it just freaks out if any loop runs too many times (in flash's case 25,000). So a clever coder can get past this.
Reply | Thread | Link



MegaZone
  User: zonereyrie
  Date: 2006-09-06 00:19 (UTC)
  Subject:   (no subject)
I don't turn of JavaScript because I find the functionality is more than worth the risk. I *LIKE* things like pulldowns that auto-submit when you change them to select something. I like intelligent navigation and form fields that present options based on input to previous fields. I *LOVE* things like Google Maps.

I am 100% for AJAX and browser based applications, and that requires some intelligence in the browser. I see absolutely no fundamental problem to JavaScript. The problems come from poor implementations. It is possible to sandbox JS properly, and if that were the case there wouldn't be trouble. but bugs happen.

I find sites that still use server submits for everything to be slow and annoying. I always wonder why they're stuck in 1995 and when they'll get with it and do it the right way - browser side. The server should be a fallback for degraded use, not the primary.

I have never seen a good reason to turn off JavaScript entirely. All I've seen are reasons not to use IE, because the JSscript implementation is hideous. The bugs that have come up in Mozilla I could accept until patched, which happens rapidly.

In Firefox I disable some JS features - I don't allow it to remove navigation bars, to override menus, or to move/resize existing windows. That's all rude behavior.
Reply | Thread | Link



Ben Cantrick
  User: mackys
  Date: 2006-09-06 00:39 (UTC)
  Subject:   (no subject)
The problems come from poor implementations. It is possible to sandbox JS properly, and if that were the case there wouldn't be trouble. but bugs happen.

It's certainly true that properly sandboxed JScript wouldn't be nearly as much of a problem. But you can say the samething about Sendmail, and it'd also be true. And how many people have been totally p0wned by the never-ending stream of sendmail bugs. (Remember ol' Robert Morris?) To take the analogy to the absurd extreme, a properly reinforced Pinto wouldn't blow up when it was hit from behind, either. But at some point you just have to look at history and say "This isn't worth the effort. We need to throw it away and start from scratch." I think we're long past that point with JavaScript.

I'm not sure why Google maps can't be done (faster, even) with a Java Applet. Embedded Java Applets have their problems, to be sure. But at least security was built into Java at some reasonable point near the start. If we're going to have a reasonably secure scripting language for the web, security is going to have to be a primary design goal - not a half-assed afterthought that we still can't get right after ten years of trying. Everyone got that ActiveX was a bad idea because the implementation was utter crap, but somehow we don't seem to be learning the same lesson with JavaScript.

My problem is not so much with the language itself, which I think is fine as scripting languages go. (Though, personally, I'd use PERL first.) It's more that someone decided that A) it would be a good idea to embed it in a web page and B) someone else thought it would be a great idea to have your web browser run arbitrary scripts with no real security. It's hard to blame the language for the stupidity of the implementer. But unfortunately the fact that the language is reasonable doesn't make the implementation not suck.

So, we may be in violent agreement here. ;]
Reply | Parent | Thread | Link



MegaZone
  User: zonereyrie
  Date: 2006-09-06 00:53 (UTC)
  Subject:   (no subject)
Sure, just about every major software package has had flaws. Even Java has had some security holes - the sandboxing on Java isn't perfect. At this point I don't know that Java is really better than one of the better JavaScript/ECMAScript sandboxes, like Mozilla. Security was designed into JavaScript from the very start - the earliest specs for implementors included sandboxing, preventing all access to the local system, etc. Later Netscape introduced Signed Scripts to allow for local access - just like signed Java Applets. The specs were, and are, there - implementors, Netscape included, didn't do a great job of it. Some of that was the code they were working with. The old Netscape codebase was such a fuster-cluck that securing it was like pluging a levee with Kleenex wads. It didn't get better until a new engine was written as part of the Mozilla effort.

Microsoft did a hideous job as well - but some of that was deliberate. Along with ActiveX, they designed JScript (and VBScript - remember MS pushed that in the browser first), to be able to do local things because it was 'more powerful'. Whereas Netscapes philosophy, if not always their code, was to keep things sandboxed in the browser, MS wanted to tie things to their OS - so they put ties from the browser into the OS. Which has been a never-ending source of pain.
Reply | Parent | Thread | Link



Ben Cantrick
  User: mackys
  Date: 2006-09-06 01:27 (UTC)
  Subject:   (no subject)
Even Java has had some security holes - the sandboxing on Java isn't perfect.

Didn't want to imply this at all. Java applets have had plenty of security issues in the past, and I have no doubt that there are plenty more lurking. I'm betting that the next ten years will bring at least one more "remote root compromise" level of Java sandbox flaw. If only some kind of buffer overflow, since we programmers can't seem to make a single daemon or other network connected program that doesn't have a buffer overflow it in somewhere.

Security was designed into JavaScript from the very start - the earliest specs for implementors included sandboxing, preventing all access to the local system, etc.

This is very interesting, and I did not know about it. I'd like to read up on it, but I can't seem to find anything about it on Google. I could easily be using the wrong search terms though. Got a URL for me?

Searching on "javascript security" finds a lot of stuff like this and this, but those are all about the broken implementations currently being used, not about what the right thing to do(TM) is or what is correct to spec. I'd really love to read the actual specs.

The old Netscape codebase was such a fuster-cluck that securing it was like pluging a levee with Kleenex wads. It didn't get better until a new engine was written as part of the Mozilla effort.

No argument about the old Netscape codebase. But given that the Moz guys seem to be strongly implying that they're not convinced that their security model does what it's supposed to even today... I think I'll still take Java applets over JScript right now.

Few people would like it more than me if JScript turns into a secure, robust platform next week. But I gotta say, based on history... I just don't see it happening.

Microsoft did a hideous job as well - but some of that was deliberate. Along with ActiveX, they designed JScript (and VBScript - remember MS pushed that in the browser first), to be able to do local things because it was 'more powerful'. Whereas Netscapes philosophy, if not always their code, was to keep things sandboxed in the browser, MS wanted to tie things to their OS - so they put ties from the browser into the OS. Which has been a never-ending source of pain.

Absolutely no disagreement there. Not using IE, as you recommended a few posts us, is a *great* idea. MS more than dropped the ball with their browser security. In fact, they pretty much threw an intentional intercept into their own end zone. Nice going, guys.
Reply | Parent | Thread | Link



MegaZone
  User: zonereyrie
  Date: 2006-09-06 01:47 (UTC)
  Subject:   (no subject)
I'm trying to find something about the early versions of JS - but, of course, all of the online references I find have been updated for 1.5 and don't talk about 1.0/1.1, etc, except in brief history notes.

I worked with JS starting from the first releases in Netscape, I even went to a one-day class on JS1.0 when it first appeared, to start using it for things like form validation. So a lot of it is just stuff I remember from the time. Developer.netscape.com used to have some good stuff, but it went away. Some if it is at Mozilla.com now, but not all.
Reply | Parent | Thread | Link



browse
May 2015