Archive
Say hello to the new math!
Yesterday at my company, some of my department stopped work for a day to participate in an “enrichment” course.
We are a large company that can afford such things, and it can be interesting and useful.
We even have the facilities for lectures right at the office (usually used for instructing new hires) so it is very convenient to invite an expert lecturer from time to time.
This time the lecture was about Angular.
As I am not a web developer, I was not invited, but the lecture room is close to my cubicle so during the launch break I got talking to some of the devs that participated. And of course we got into an argument about programming languages, particularly JavaScript.
I wrote before on this blog that I hate JS with a vengeance. I think it deserves to be called the worst programming language ever developed.
Here are my three main peeves with it:
- The == operator. When you read a programming book for beginners that teaches a specific language and it tells you to avoid using a basic operator because the logic behind it is so convoluted even experienced programmers will have hard time predicting the result of a comparison, it kills the language for me.I know JS isn’t the only language to use == and ===, but that does not make it any less awful!
- It has the
eval
built in function. I already dedicated a post to my thoughts on this. - The language is now in its 6th major iteration, and everyone uses it as OO, but it still lacks proper syntax support for classes and other OO features.
This makes any serious piece of modern code written in it exceedingly messy and ugly.
But if those 3 items weren’t enough to prefer Brainfuck over JS, yesterday I got a brand new reason: it implements new math!
Turns out, if you divide by 0 in JS YOU GET INFINITY!!!
Yes, I am shouting. I have a huge problem with this. Because it breaks math.
Computers rely on math to work. Computer programs can not break it. This is beyond ridiculous!
I know JS was originally designed to allow people who were not programmers (like graphics designers) to build websites with cool looking features like animated menus. So the entire language was built upon “on error resume next
“ paradigm.
And this was ok for its original purpose, but not when the language has grown to be used for building word processors, spreadsheet editors, and a whole ecosystem of complex applications billions of people use every day.
One of the first things every programmer is taught is to be ready to catch and properly handle errors in their code.
I am not a mathematician. In fact, math is part of the reason I never finished my computer science degree. But even I know you can not divide by zero.
Not because your calculator will show an error message. But because it brakes the basic rules of arithmetic.
Think of it this way:
if 5 ÷ 1 = 5 == 1 × 5 = 5 then 5 ÷ 0 = ∞ == 0 × ∞ = 5 Oops, you just broke devision, multiplication and addition.
But maybe I am not explaining this right? Maybe I am missing something?
Try this TED-ed video instead, it does a much better job:
If JS wanted to avoid exception and keep the math, they could have put a NaN there.
But they didn’t. And they broke the rules of the universe.
So JS sucks, and since it is so prevalent and keeps growing, we are all doomed.
Something to think about… 😛
eval is evil!
Last week a friend of mine got an email pretending to be from Linked-In.
It looked suspicious so she forwarded it to me for inspection.
A quick look at the HTML attachment showed that it contained some very fishy JavaScript.
One notable part of it was a large array of floating point numbers, positive and negative.
As some of you might have guessed, this array actually represented some more scrambled JavaScript.
Now, I am not a security expert, but I was curious what this thing did. I know there is some tool to test run JavaScript, but I did not remember what it was called, so I just run Python in interactive mode to make a quick loop and unscramble the floating point array.
What I found was JavaScript redirecting the browser to a very suspicious looking domain.
Downloading the content of the URL resulted in more JavaScript, this time with a very long sting (over 54000 bytes long!).
Again I found the unscrambling function, redone it in Python, and received what was clearly a malware injecting JavaScript that was just over 15 thousand bytes long!
The funny thing was, the malware script was not obfuscated (aside from all whitespace being removed), so I could actually see a function called “getShellcode”.
Despite being quite long, it was easy to see that the script used some vulnerability in Flash Player versions 10.0.40 to 10.2.159 to do it’s nasty business.
I have yet to unscramble it’s shellcode payload, so I am not sure what that business is exactly.
But, this package is not unique. I am sure there are thousands of variations of it in the wild.
Why am I bothering to write about it?
Because the main component used to hide the truth about what this malware does is JavaScript eval function.
In fact, it is used twice, both in the first stage JavaScript attached to an email, and in the second stage script that actually tries to inject the malware.
Which got me wondering: why the hell did the designers of JavaScript put it there???
I know JavaScript is not the only language to have such function.
I know it has some legitimate uses (though I am not sure how many).
And as a developer, the last thing I would want to encourage is reducing a programming language’s power.
But seriously, is the huge security risk really worth it?
After all, this is a Browser scripting language, something you might download and run without even being aware you are doing it.
Even the name of the function sounds almost “evil” 😛
So here is my rant of the day: ban eval from JavaScript.
Who is with me?