IS IT TIME TO “GO”?
Today, Google introduced their new systems language called “Go”. Where does the name “Go” come from? Well, lets put it this way; the documentation states that a great name for the debugger would be “Ogle”. I will let you put the pieces together. “Go” is Google’s alternative to C or C++. The primary difference is that they have removed many of the language constructs, which either contributes to coding errors or common problems related to secure coding. In addition, they have added fundamental support for concurrent execution and communications, garbage collection, and even multiple return values. All of these features are interesting, and would be a joy to have in a major language; however, none of them are groundbreaking in nature.

LOOK BOTH WAYS BEFORE CROSSING
Everyone is looking in the wrong direction. Most of the literature and editorials that I have read so far all seem to focus on the fact that Google has introduced a new language to potentially compete or replace C/C++ or Java. They are trying to figure out why the world needs another language. Is “Go” better than C++? Why can’t you just create new classes in C++? Should major new applications be written in “Go”? How does “Go” compare with Java? They are all missing the point. Google did not create a new language just for the fun of it nor the technical challenge of it all. Furthermore, this is NOT a battle of the computer languages; this is a battle for the next major operating system: The Browser Based Operating System. The introduction of the “Go” language is a key strategic move in this direction.

CAUTION…CURVES AHEAD
What does a language have to do with a browser!? Months ago, Google quietly introduced a powerful new feature into the Chrome browser called Native Client. This is essentially a sandbox, which can run untrusted x86 native code. This has major implications. This provides browsers like Chrome the ability to perform intense computational tasks that far exceed the speed and capabilities of Flash/Java/Javascript/or Silverlight. In a perfect world, a traditional ActiveX control would be cross platform, unable to harm your computer/browser, and executed in a secure runtime environment. This is exactly what the Native Client provides! However, standard compilers cannot create code that is compatible with the Native Client runtime environment. According to the paper “Native Client: A Sandbox for Portable, Untrusted x86 Native Code” presented by Google at the 2009, IEEE Symposium on Security, there are seven key constraints that must be met in order for code to run in the sandboxed environment:

1) Once loaded into memory, the binary is not writable, enforced by OS-level protection mechanisms during execution.
2) The binary is statically linked at a start address of zero, with the first byte of text at 64K.
3) All indirect control transfers use a nacljump pseudo-instruction.
4) The binary is padded up to the nearest page with at least one hlt instruction (0xf4).
5) The binary contains no instructions or pseudo-instructions overlapping a 32-byte boundary.
6) All valid instruction addresses are reachable by a fall-through disassembly that starts at the load (base) address.
7) All direct control transfers target valid instructions.

Except for constraint #5, most compilers don’t meet the requirements to produce valid code for the Native client environment. Google has introduced experimental modifications to GCC and other tools to produce Native Client applications, but they are all based around forcing an existing coding methodology to meet a new more secure execution environment. This technique inevitably leads to many compromises, and create a disconnect between the language, the programmer, and the reality of the seven aforementioned constraints.
The “Go” language will provide a modern day, systems type language, which will create code from the ground up that meets the constraints listed above. In addition, programmers won’t feel like they have to compromise on functionality or capabilities when developing software, because Google has replaced all important “C” language constructs, such as Pointer arithmetic, with secure and very usable alternatives such as Slices.

CAN ANDROIDS DRIVE?
Google’s mobile platform, “Android”, certainly wont be excluded from the master plan. Currently, the premier language for development on Android is Java. However, Java is considered a high-level language and always struggles to meet the performance capabilities of a real systems language such as C or C++. It is noted in the FAQ that ARM chip support is currently under development has already been tested on Android phones. In upcoming years, you will find that Go will be used to develop plug-ins for the already robust Android browser, and also as an alternative language for Android mobile application and driver development.

FULL SPEED AHEAD
There are many interesting features in the “Go” language that will make it a very intriguing tool for general application development, such as garbage collection, fast compilation, and flexible typing. However, in the near term you can expect the “Go” language to mature quickly and fully support the Native Client environment. Currently, this support is not complete, however, it is certainly a high-priority for Google. Looking ahead, I believe that this “Go” language will be the premier language for the development of plug-ins for the Chrome browser. Ultimately, it will become the foundational language of choice as the Google OS fleshes out and becomes a reality.

• 4 Comments

The security community has recently learned of the new security exploit that will allow any normal, non-privileged, user to become the most powerful user on a Linux system - “root”. This elevation of privileges means that you can no longer trust any user on your Linux box if it is running a version of the Linux kernel from 2.6.17 all the way to 2.6.24.1. Any low privileged shell account can now become an attack vector. Just imagine a system where every user is potentially an administrator!

What is affected?

Basically all new Linux kernels built from kernel source from June 17, 2006 when the Linux kernel version 2.6.17 was released, until today. Surely, a fix will be in an upcoming kernel update, but as of today, February 10, 2008, it is not in the production kernel source distribution. It’s possible that up to a million copies of Linux containing this attack vector are in production today.

The proof of concept code is shown at http://www.milw0rm.com/exploits/5092 . This short little chunk of code makes all of this mayhem possible, and is simple enough to be compiled and executed by anyone.

I have seen the potential fix to this problem in Linux. The kernel is missing a simple privilege check. The kernel code is lacking a call to the function “access_ok()” to prevent unauthorized data from being copied from userspace to kernel memory. You can see the potential fix here –> http://git.kernel.org/…

What Now?

Well, there are two challenges:
A) How do we get ALL of these vulnerable machines to a new version of the kernel.
B) What will be the impact on existing applications on critical servers.

Are our servers OK?

We don’t know how long this particular exploit has been in the wild and available to the underground community. That leaves us with the daunting question question, “Has this type of exploit already been executed on our systems? And if so, what did they do?!?” It is becoming increasing important to understand exactly what is changing on our servers and why.

What’s in the future?

Right now, everyone is considering the impact of this exploit from a shell prompt. However, I believe the REAL threat will come in the future. Expect new exploits to be developed using this proof of concept code. Security professionals should be prepared for code that will use a buffer overflow techniques to inject code into servers that will elevate to ‘root’ user/privilege, and perform whatever task the hacker may have in mind. In plain English, it means, that web servers that commonly run under the low privileged account of “nobody”, will be COMPLETELY exploitable by simple buffer overflow techniques.

Hackers will literally go from a “nobody” to a somebody…”root”. Without a doubt, addressing this particular exploit will be a high priority for administrators for the weeks to come.

• 6 Comments

I find the introduction of Apple’s new Apple TV very interesting. I have noticed that there is as much interest in hacking the Apple TV unit, as in the capabilities of the unit itself! In fact, it appears as if there is perhaps more interest in the possibilities of a hacked unit, than for existing capabilities.

That leads one to wonder if in reality, the consumer market is actually more interested in a low cost, attractive, consumer friendly OPEN media center. The $300 price point of Apple TV is perfect. I would love to see this all taken a step further, and for a company like Dell to introduce their own media center unit. A unit that would be called something like “OpenTV”. It would be a general purpose Media Center Unit with a price point of about $250-$300, BUT, would come preloaded with LinuxMCE (www.linuxmce.org), but with a philosophy that would welcome people to install their Media Center Control Software of choice. This would be a wonderful new platform projects like the excellent XBox Media Center (XBMC) (www.xboxmediacenter.com) to be ported to, and would definately spark tremendous innovation in the Home Entertainment space.

People dont want “computers” in their living room…but they do crave the power and benefits that they could bring to their entertainment experience. A vendor adopting my OPENTV concept would be a welcome addition to this exciting new segment of the consumer market.

• 3 Comments