Your Browser: A General Purpose Remote Code Execution Tool

Google Chrome web browser security warning message

I've been reviewing the current state of Internet Privacy.

It's still a mixed bag and my conclusion is that it will remain so for quite some time.

Efforts to provide Internet Privacy are varied, depending on which ISP is employed.

The primary means for conveyance to a target website to do any kind of task is the web browser.

To put security risk into context, the web browser is a remote code execution tool.

Yep.  Let that sink in for a minute.

Where ever the user goes, the browser is set to 'trust' a remote stream of bytes which get 'interpreted' as program instructions on your PC by the web engine.

Sounds quite troubling when you think about it really.

I mean, your browser is one big catcher's mit and absorbs everything it sees in an attempt to execute instructions sent from a remote web server.

So, this catcher's mit is by default a 'security risk'.

Different software vendors take different approaches to the responsibility of writing their software in a manner that ensures it should always operate securely.

For example, Internet Explorer on Microsoft Windows, is written by Microsoft and employs 'protected mode', something akin to a software sandbox, but, technically isn't.

Google Chrome for Windows is designed with a quasi-sandbox by Google Engineers.  But they have publicly stated it cannot stop certain kinds of exploits (Javascript DLL injection) from successfully executing and gaining administrative control on Legacy Windows.  This is a fact.

But, that isn't really my point.  In each software project some 'defensive' coding has or has not taken place.

I've reported in the past that, where Fedora Linux is concerned, users running Firefox, the default installed browser, are placed in a 'real' sandbox, called Linux Security Modules (LSM) and the particular module used by Fedora is SELinux.

From a security standpoint, this is a prime differentiator between Linux and Windows.

An exploit may propagate on Windows running Chrome.  It will never propagate using Linux with SELinux.

The word 'never' comes with a catch.  You see the browser's memory space is up for 'fair game' and various code, Java, Javascript can execute remotely exposing certain parts of your running PC.

In theory, nothing bad should happen and it is assumed that code in the browser PID will never escalate to the Admin level.

But what it is doing in its own memory space is an open question.  The issue of cross site scripting remains an unsolved problem.

In this context, if a user chooses to employ a browser-based security tool designed to protect their local PC, this sets up the conditions  -- a 'fictional' exploit may, for example, attempt to steal a local browser's in-memory private keys for encryption.

So, you see, I am revising my thinking.  I'm not sure any more about using the browser for any kind of security.  It's that risky.

Using compiled, well maintained free standing open source security applications is entirely a different matter.

For example, I have Gmail.  But I don't use the browser client to access it.
I use GNOME Shell's integrated Evolution Email client, which is also used to prepare outgoing mail using GnuPG (OpenPGP) encryption.

The PID for decoding/encoding gmail runs in Evolutions local memory space, not in a browser.  Once the email is encrypted, signed, it is then and only then sent and a copy gets stored (IMAP) on the Gmail web server, in PGP encrypted form.

That's a routine process I feel confident in completely.

The notion that other software vendors can fork GnuPG and refactor it in Javascript troubles me.  This is precisely what Google is doing in their End-to-End encryption project, currently in Alpha.

The whole end to end encryption runs as javascript in the browser.
That puts the whole premise of security in the hands of the browser.

It's not acceptable.  Even now, I am rethinking how MEGA works.  Again, here, there is secureboot.js code running in your browser.

I believe there has to be a total segregation from the browser for any kind of security tool client application.  It must be compiled.  It must be open source and it must employ upstream industry standard GnuPG OpenPGP.

The browser will always be a target for attack.  Always.  Letting it also run your security is a fundamental mistake.  -- Dietrich

Related articles

• Protect your privacy - Help GnuPG hire a second developer!

Read More

Microsoft Windows 8.1 Legacy (x86) - UNSAFE FOR GENERAL USE

by Dietrich Schmitz

You are reading this wondering what that means. Google Engineers have, in earnest, attempted to bolster Chrome for Windows by placing it in their own crafted (Not Microsoft -- they don't have one) security sandbox.

Despite their best efforts, they have posted to their Chromium developer website that they cannot guarantee your security if you use Microsoft Windows.

Here is their disclaimer:

Other caveats

The operating system might have bugs. Of interest are bugs in the Windows API that allow the bypass of the regular security checks. If such a bug exists, malware will be able to bypass the sandbox restrictions and broker policy and possibly compromise the computer. Under Windows, there is no practical way to prevent code in the sandbox from calling a system service.

In addition, third party software, particularly anti-malware solutions, can create new attack vectors. The most troublesome are applications that inject dlls in order to enable some (usually unwanted) capability. These dlls will also get injected in the sandbox process. In the best case they will malfunction, and in the worst case can create backdoors to other processes or to the file system itself, enabling specially crafted malware to escape the sandbox.

That's quite troublesome when you think about it. Google Engineers post up a 'caveat' -- their legal disclaimer, if you will.

Simply put, Windows 8.1 legacy (x86) uses a legacy code base going all the way back to the Windows 2000 WinNT kernel.

Microsoft cannot fix the security issues which are under eternal attack unless they completely rewrite the operating system from the ground up. Enterprise is 'married' to the operating system with applications which must run 24x7. Microsoft cannot rewrite the code which is heavily depended upon. They have a dilemma and they really don't want you to know about it. They just keep diverting your attention to 'the attackers' away from themselves as though they have no responsibility.

This is the cost of using proprietary software. Unlike Open Source Linux, no one can see the code of Microsoft Windows, review it, inspect it for defects -- FOR MICROSOFT EMPLOYEE EYES ONLY.

This is the disadvantage that one accepts when agreeing to the Microsoft software licensing terms. Microsoft own the code -- the Licensee does not.

So, why not consider making a switch today to Gnu Public Licensed Linux and own the code? It's yours for free and it is so secure, I'll even say Fedora 20 Linux is the safest operating system on the Planet.

Fedora 20 Linux running LXDE

Be safe with Fedora Linux.

I stake my reputation on it.

-- Dietrich

Related articles

• Debian, Ubuntu Cave In: Standardize on Systemd
• Sandbox? What Sandbox? -- Fedora Has You Covered
• Microsoft Windows 8 Legacy: An Unacceptable Level of Risk

Read More

The JSON API: An Example

by Dietrich Schmitz

I'm not one to let things go.  If I can't figure something out, it simmers and brews, sometimes for days, even weeks at length until I get an answer.

That was my experience with JSON.  I'm not a web uber geek by any stretch of the imagination and have spent over two decades doing IT programming all without coding a line of html.

I am quite fine with that.  But I was confronted by what seemed to be a simple exercise in configuring this website: having it return a list of posts 'by Author'.

Well, no.  It turns out that there isn't a lever, toggle, switch one can pull to make that happen.  Yes, a post does indeed have category tags, but to have that work reliably one must explicitly append a 'tag' to the post, i.e., the name of the Author.  One omission will result in the query missing a post.  That isn't acceptable.

So, I thought there must be a way to get that seemingly basic information from a post. Yes?

Yes!  It turns out that Google has an array of APIs to their product line and, categorically, Blogger has its very own.  It's called Javascript Object Notation or JSON for short.

This is good news. Yes?

So, I proceeded to pour over the documentation in earnest hoping that if I stared long enough and tried various API calls I could get it to cooperate.

This went on for over two weeks with my poking at it periodically without success.

Finally, I decided to try a simple test to see what Google's API would return using JSON.  It is pretty basic:

When I saved the html and opened the test.html from my local share, it returned to the screen 'Undefined' 'Undefined' as if to taunt me once again.  I was taunted.

So, I double-checked my settings in the Google API console, even recreated my apikey just to be sure and then took just the RESTful portion (I've obfuscated the api key as 'xxxxxxxxxxxxxxxxxx'), and ran it from a terminal command line to see what was in the response.  It returned 200 OK but the response included information I had not seen up to this point, a clue to what was keeping my simple JSON query from giving over the goods:

// API callback
handleResponse({
 "error": {
  "errors": [
   {
    "domain": "usageLimits",
    "reason": "dailyLimitExceededUnreg",
    "message": "Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup.",
    "extendedHelp": "https://code.google.com/apis/console"
   }
  ],
  "code": 403,
  "message": "Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup."
 }
}
);

Ah hah!  Now we are getting somewhere.  So, in spite of my due diligence in obtaining an api key, it turns out that obtaining an api key has a very limited quota so I had spent it in my previous incantations and the message was clear in saying I should 'sign up'.  So, yesterday, late in the day, I signed up and sent off the form to Google which replied that it might take as much as several days before my request would receive a review.

Late last night, an email came from a chap at Google who enabled my apikey.  I was quite pleased with the quick turn-around and sent him a thank you email.

With that I dispatched directly back to firing off my test.html opening it from my local share.  Much to my pleasant surprise, it dutifully responded with a response:

My test.html to exercise the Blogger JSON api confirms success

So, as you can see above, the issue wasn't my JSON--it was the fact that the apikey was not 'authorized'.  Once enabled it worked flawlessly.

This now opens the door to an array of possibilities for adding addition features, widgets, etc.

Initially, I would like to have a link in the post 'About the Author' box which when clicked will open a browser tab and display the title and link to each article belonging to the Author.  Should be easy right?  That is on today's plate.

Okay then, that is just a very simple JSON api example which I hope might help some of the readers to get motivated to do the same for their website.  -- Dietrich

Related articles

• JSON: The Undisputed King of Web Interchange APIs
• Google APIs finetuning Cloud Storage JSON API
• Designing A RESTful API That Doesn't Suck
• JSON for jQuery EasyUI
• Parsing JSON API response with php

Read More

JSON: The Undisputed King of Web Interchange APIs

by +Dietrich Schmitz

I have been roaming over the InterTubes in search of various technical information as regards this website.

It can at times be like looking for a 'needle in a haystack' when it comes to pinning down a specific method of getting your website to function in a specific way.

Like for instance, it occurred to me that there ought to be a 'standard way' to query (via some application programming interface or API call) a chunk of information concerning activity taken on the website, be it global website metadata, something about a post or collection of posts or about a specific author--stuff like that. (Credit image right: www.json.org)

Well, the bad news is, there really isn't one 'standard' way.  The good news is, today at least, you have more than one way to obtain that information at your disposal.  But that can create confusion.

In fact, if you do the requisite research as I have (in an effort to answer a few needs here on Linux Advocates), you might at first be overwhelmed by the sheer surplus of data, help websites, how-to's, 'know-it-all' posts that confront you, all bombarding your brain on a Google search adventure.

Fortunately, in the case of Blogger, the documentation for their web application programming interface is right at your fingertips here.

The methods you ultimately choose for reaching into your website's data cache will depend on which web engine you have chosen and which tools you employ.

So began my journey into the wonderful world of Javascript Object Notation, otherwise known as JSON.

For many website platforms, it might seem most direct to simply write a SQL to obtain the data needed on the backend database, used to store persistent data.  And on many websites, that is frequently done.

As for Blogger, the web monkey (Me) doesn't have access to a database per se.  The database, if there is one, isn't surfaced by Google.  Instead, what they expose is the aforementioned API, JSON.  A seemingly circuitous path, set of gymnastics a code monkey must contort into to get at the needed data.

Some things come more easily for dedicated programmers than the less initiated.  For starters, having a higher threshold of 'pain' works to one's advantage--when I can't find an answer, I obsess for days, gnash teeth, fidget, until I hit on the answer--pretty routine masochistic self-imposed torture.  Most programmers accept this as part of their occupation and resign themselves to pouring over on-line technical documentation, some better and some less so, all in a vengeful determined effort to divine the 'magic' to getting from point A (the problem) to point B (the solution)--returning the correct piece of data or desired function (behavior), hopefully.

So, after many starts and stops, interruptions, staring for long periods of time, ranging across the Internet (one time there was a sign 'You have reached the end of the Internet--turn around and go back'), I was finally feeling like I had decoded the 'Rosetta Stone' and came up with a subset of code which might be your 'prototypical' example for querying the JSON API:

Good Code Monkey.  Now press the button and take the pellet.  There.

Pretty much the above JSON code lives neatly inside of Javascript and co-exists nicely all wrapped up in a tidy HTML page.  One can also use just about any programming language under the Sun--there's most likely a library which encapsulates JSON for your preferred programming tool, be it PHP, Perl, Python, what have you.

Along the way, in my various readings, I came across this sterling article which summarizes quite well why JSON is revolutionizing the 'Internet of Things'.  The author Luc Perkins keenly observes:

"...Ten years ago, XML was the primary data interchange format. When it came on the scene, it was a breath of fresh air and a vast improvement over the truly appalling SGML (Standard Generalized Markup Language). It enabled people to do previously unthinkable things, like exchange Microsoft Office documents across HTTP connections. With all the dissatisfaction surrounding XML, it’s easy to forget just how crucial it was in the evolution of the web in its capacity as a “Swiss Army Knife of the internet.”

But it’s no secret that in the last few years, a bold transformation has been afoot in the world of data interchange. The more lightweight, bandwidth-non-intensive JSON (JavaScript Object Notation) has emerged not just as an alternative to XML, but rather as a potential full-blown successor. A variety of historical forces are now converging and conspiring to render XML less and less relevant and to crown JSON as the privileged data format of the global digital architecture of the future. I think that the only question is how near that future is.

I strongly believe that this transformation can be attributed to four broad trends, which I’ll discuss in turn:

1. APIs (application programming interfaces)
2. Big Data
3. The Internet of Things
4. Full-stack JavaScript..."

So, during my journey learning JSON, I have reached the conclusion that in today's 'mash-up' Web 2.0 world where one website incorporates chunks of data from another unbeknownst to the average user, behind the scenes is most likely JSON at work.

Ten years ago, XML might have been the only solution for serializing and exchanging data over http.
Even more sophisticated today is using JSON over Websockets which is only beginning to turn up in some of the more advanced website coding practices.

JSON's lightweight nature requires far less effort than XML and integrates into most website frameworks now as a plugin architecture if not present in its default installation.


So, does this fit with your view on the 'Internet of Things' and experience with the newest programming paradigms?  Please give your feedback!

-- Dietrich


END

Related articles

• Who Is This JaSON Guy, Anyway?
• Google APIs finetuning Cloud Storage JSON API
• Binding to JSON & XML - Handling Collections
• API JSON to XML

Read More