I'm proud to announce my first chrome extension!

[Isaac]

What's it do? Temporarily disable javascript on a page you're going enter, by right clicking and selecting an option to open the link without javascript allowed on that page. If you realize you want javascript, close the tab and open the link again and javascript will return!

https://chrome.google.com/webstore/deta ... iccfohbnmh


If you want to see how it works go here:
http://descentbb.net/viewtopic.php?f=7& ... 19#p342119

[Sergeant Thorne]

I don't use Chrome because Google is evil incorporated cleverly disguised as awesome. Also, while I would not claim to be a heavy surfer, it's not often that I feel the need to disable javascript.

[Tunnelcat]

Nice work Issac. But what about that newly discovered Bash Bug with Linux?

http://www.cnet.com/news/bigger-than-he ... llshocked/

[Krom]

I don't use Chrome because Google is evil incorporated cleverly disguised as awesome. Also, while I would not claim to be a heavy surfer, it's not often that I feel the need to disable javascript.

I run Firefox with NoScript (adblock plus also helps) which is a whitelist that blocks java/javascript/flash/etc by default. Thanks to running those I've dodged embedded malware several times. So this chrome extension could definitely save your system from some drive by downloads if you use it properly even if it won't be quite as effective as NoScript.

[Isaac]

Nice work Issac. But what about that newly discovered Bash Bug with Linux?

http://www.cnet.com/news/bigger-than-he ... llshocked/

It's kind of a big deal, but not as big as the media is making it sound. You'd have to understand what bash is and how permissions work.

A hacker can't just locate my netbook on LAN and start asking it questions. The hacker wouldn't even get a response from my netbook. The same goes for most servers, but there are some exceptions. Even with those exceptions it can still be difficult.

Jeff, correct me if I'm wrong, but it's not like Heartbleed. Heartbleed on a server would be exposed to the general public, because of oauth. "Shellshock", on the other hand, isn't exposed to the general public, unless your server or linux laptop is setup in a specific way to give outside users access to the exploit.

On shared hosting, all the websites are on the same virtual host. Using CGI scripting I can run bash commands and get everything I want, even crash the server, but I don't have access to other user accounts in the home folder. This isn't a bug. This is normal access. If I were to write a cgi script that gave users on the internet a text box that let them submit their own command lines they would be able to see everything on my account, because my useraccount owns the cgi script that created it. All the programs that the CGI script can run in bash would be subject to my user permissions, no matter what they pipe through them.

So this chrome extension could definitely save your system from some drive by downloads if you use it properly even if it won't be quite as effective as NoScript.

Large professionally made extensions tend to lag my netbook. I don't know why they make them so large, but they do. They span hundreds of lines of code, for menus and have databases. Maybe I'm in the minority in 2014, but my only problem is with news sites. Most other sites use minimal javascript for assist the page, like this one.

I don't use Chrome because Google is evil incorporated cleverly disguised as awesome.

The extension also works with Chromium.

Also, while I would not claim to be a heavy surfer, it's not often that I feel the need to disable javascript.

My netbook, which is my only computer, can't handle six ajax processes firing off at once, which normally import more javascript. It's insane. News sites are the worst for me.

[Jeff250]

It's kind of a big deal, but not as big as the media is making it sound. You'd have to understand what bash is and how permissions work.

A hacker can't just locate my netbook on LAN and start asking it questions. The hacker wouldn't even get a response from my netbook. The same goes for most servers, but there are some exceptions. Even with those exceptions it can still be difficult.

Right, you need to be running some service where an attacker can 1) fully control some environment variable and 2) spawn a bash shell.

Requirement one is commonly satisfied with CGI applications. CGI is an old method of writing web applications where the web server passes information about the request to the corresponding CGI script via environment variables.

Requirement two is trickier. On machines where /bin/sh is symlinked to /bin/bash, any call to system() or popen() would trigger a launch of bash, as would the CGI script execve()ing any shell script. On many unix os's including debian and Ubuntu, /bin/sh is not symlinked to /bin/bash, and so they would be more difficult to exploit. Still, if your CGI script calls any script (such as gunzip) that explicitly has a /bin/bash hashbang, then you're still vulnerable.

Jeff, correct me if I'm wrong, but it's not like Heartbleed. Heartbleed on a server would be exposed to the general public, because of oauth. "Shellshock", on the other hand, isn't exposed to the general public, unless your server or linux laptop is setup in a specific way to give outside users access to the exploit.

Because of oauth? Heartbleed was a vulnerability in OpenSSL, most commonly exposed in HTTPS servers. If you're using oauth, you're probably also using HTTPS, but that's the only connection that I know of between oauth and Heartbleed.

On shared hosting, all the websites are on the same virtual host. Using CGI scripting I can run bash commands and get everything I want, even crash the server, but I don't have access to other user accounts in the home folder. This isn't a bug. This is normal access. If I were to write a cgi script that gave users on the internet a text box that let them submit their own command lines they would be able to see everything on my account, because my useraccount owns the cgi script that created it. All the programs that the CGI script can run in bash would be subject to my user permissions, no matter what they pipe through them.

Right, you would still need a privilege escalation vulnerability to get root on the server, but root is overrated.

[Isaac]

Oops, I meant OpenSSL. The open part confused me.