{"id":3219,"date":"2013-02-07T15:32:59","date_gmt":"2013-02-07T05:32:59","guid":{"rendered":"http:\/\/www.flamingspork.com\/blog\/?p=3219"},"modified":"2013-02-07T15:32:59","modified_gmt":"2013-02-07T05:32:59","slug":"being-highly-irresponsible-or-howto-dos-nearly-all-rdbmss","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2013\/02\/07\/being-highly-irresponsible-or-howto-dos-nearly-all-rdbmss\/","title":{"rendered":"Being highly irresponsible (or, HOWTO DoS nearly all RDBMSs)"},"content":{"rendered":"

In my linux.conf.au 2013 talk, I had a big slide telling the audience how to do a simple Denial of Service attack against a MySQL server (post login). This was only one example of many others I could give, but I think it’s the simplest, and only requires the mysql command line tool and a single command. FYI, this also applies to PostgreSQL but I’ll leave the specifics up to somebody else to write.<\/p>\n

There is a fundamental flaw in just about all MVCC databases that leaves a giant Denial of Service attack hole. It is the following: START TRANSACTION WITH CONSISTENT SNAPSHOT followed by a bunch of waiting. Sine the database server has to maintain this read view, InnoDB will continue to grow UNDO until it has to extend the ibdata1 file (system table space).<\/p>\n

It’s important to remember that you cannot shrink the system table space (unlike with file-per-table where you can just do ALTER TABLE for any individual table suddenly finding itself a lot smaller).<\/p>\n

As UNDO grows, InnoDB will faithfully expand the system table space until ENOSPC and then everything will fall in a heap.<\/p>\n

In theory, you could have a system table space that doesn’t auto-extend, but then you’re relying on code paths to error out gracefully that I can pretty much bet you are completely untested.<\/p>\n

The only real way to avoid this is doing both of the following:<\/p>\n

    \n
  1. Use kill-idle-transactions feature from Percona Server<\/li>\n
  2. have a script that checks for long running transactions and just kills them.<\/li>\n<\/ol>\n

    Similar things affect just about any MVCC database system. You’ll also see similar things with file system and volume manager snapshots.<\/p>\n

    So is it highly irresponsible pointing this out? Of course it isn’t, this should be pretty well known to most DBAs already and so should a whole bunch of other things. Remember all the things you saw in production and then went to hit your developers over the head for? Well, they’re all in this same category.<\/p>\n

    Go run giant UPDATEs, DELETEs or ALTER TABLE on a giant table in a replication setup, you’ll pretty much DoS your app as everything can’t get up to date read-only information from slaves.<\/p>\n

    Considering that this is merely scratching the top of the iceberg of ways to DoS a database server, keeping post authentication crashing bugs secret just seems… well… futile, even if you do accept security through obscurity as valid.<\/p>\n

    Further reading:<\/p>\n