Forgot your password?
typodupeerror
Security Bug Software Linux

Linux Kernel 2.6 Local Root Exploit 586

Posted by kdawson
from the batten-the-hatches dept.
aquatix writes "This local root exploit (Debian, Ubuntu) seems to work everywhere I try it, as long as it's a Linux kernel version 2.6.17 to 2.6.24.1. If you don't trust your users (which you shouldn't), better compile a new kernel without vmsplice." Here is millw0rm's proof-of-concept code.
This discussion has been archived. No new comments can be posted.

Linux Kernel 2.6 Local Root Exploit

Comments Filter:
  • Beauty of OSS (Score:5, Insightful)

    by bigtomrodney (993427) * on Sunday February 10, 2008 @04:24PM (#22372452)
    I don't think I'm the first of us to say "Ah shit".

    On the other hand though this is the beauty of open source. The problem is now known so I'm sure a fix is already on the way.
    • Re:Beauty of OSS (Score:5, Interesting)

      by IBBoard (1128019) on Sunday February 10, 2008 @04:33PM (#22372536) Homepage
      And even if it isn't on its way (and while it isn't here) you can still get the source and remove the problematic part if you don't need it. Try recompiling Flash or some other commercial software without the section that has the exploit in ;)

      .

      Note: The above assumes that the kernel compiles, which may not always go as smoothly or be as you'd like. That doesn't change the fact that it is theoretically possible, though.
    • Re:Beauty of OSS (Score:5, Insightful)

      by nacturation (646836) <nacturation@@@gmail...com> on Sunday February 10, 2008 @04:41PM (#22372640) Journal

      On the other hand though this is the beauty of open source. The problem is now known so I'm sure a fix is already on the way.
      Of course, the problem may also have been known six months ago. Not that that differs from closed source, but I don't see the openness of the code as a particular benefit in this case. The real benefit seems to be that when someone releases something as open source and they put their name on it, they're more inclined to be responsive to problems and provide quick fixes than when it's just some company's product and the developer's reputation is shielded by the company.
       
      • Re:Beauty of OSS (Score:5, Interesting)

        by RonnyJ (651856) on Sunday February 10, 2008 @04:45PM (#22372698)
        Looking at the comments at the top of the code, it's described as "quite old code" (assuming you believe the author).
        • Re: (Score:3, Interesting)

          Looking at the comments at the top of the code, it's described as "quite old code" (assuming you believe the author).
          I believe the author, but I think he was referring to the boilerplate exploit code, which is pretty awful code to tell the truth. The vmsplice bit looks brand new to me, but who knows, perhaps somebody out there really did know about the hole for the last year and a half. If so, they kept it to themselves and damage was not widespread.
    • by neomunk (913773)
      "Ah, shit" is correct. I would like to add a gracious 'Thank You nenolod' for not being a tool and keeping this little nugget to yourself.
    • Re:Beauty of OSS (Score:5, Informative)

      by fuzzix (700457) on Sunday February 10, 2008 @04:50PM (#22372742) Journal

      On the other hand though this is the beauty of open source. The problem is now known so I'm sure a fix is already on the way.

      Or already here...
      This appeared to work... [gmane.org]
      • Re: (Score:3, Interesting)

        What are the downsides/risks of using that fix/workaround? What functionality does it break or restrict?
    • Re:Beauty of OSS (Score:5, Informative)

      by Anonymous Coward on Sunday February 10, 2008 @04:55PM (#22372790)

      The problem is now known so I'm sure a fix is already on the way.
      Holy shit, no kidding - the form of an exploit which fixes the bug live in the kernel mem.
      nobody$ ./exploit
      [..]
      [+] mmap: 0xb7f29000 .. 0xb7f5b000
      [+] root
      root# ^D

      nobody$ ./disable-vmsplice-if-exploitable
      [..]
      Exploit gone!
      nobody$ ./exploit
      [+] mmap: 0xb7f34000 .. 0xb7f66000
      [-] vmsplice
      nobody$ no root for me anymore!


      By Morten Hustveit:
      "a modification of the exploit that finds the address of sys_vmsplice in the
      kernel (using /proc/kallsyms) and replaces the first byte with a RET instruction
      (using mmap of /dev/kmem)" from
      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953#14 [debian.org]

      • Re: (Score:3, Informative)

        by myowntrueself (607117)
        disable-vmsplice-if-exploitable causes kernel oops on Debian Etch with kernel 2.6.18-3-xen-686

    • by caluml (551744) <slashdotNO@SPAMspamgoeshere.calum.org> on Sunday February 10, 2008 @06:16PM (#22373502) Homepage

      I don't think I'm the first of us to say "Ah shit".
      No, you are, you really are! Google confirms it!

      Your search - "Ah shit" - did not match any documents.
  • by downix (84795) on Sunday February 10, 2008 @04:25PM (#22372460) Homepage
    And the next sound you shall hear are millions of nerds rushing into their offices to compile a new kernel on a sunday afternoon... along with the millions of cell phones ringing as the bosses read this...
  • by Anonymous Coward on Sunday February 10, 2008 @04:26PM (#22372480)
    I strongly suspect this code doesn't do what it says on the tin.
  • Thank God (Score:5, Funny)

    by Zoxed (676559) on Sunday February 10, 2008 @04:29PM (#22372504) Homepage
    Phew, lucky I run MS Windows then !!
  • Misleading (Score:3, Interesting)

    by arth1 (260657) on Sunday February 10, 2008 @04:31PM (#22372518) Homepage Journal
    This is not an universal problem. It only occurs for those kernels with a specific function compiled in that most installations won't need, and which halfway decent sysadmins won't have as part of the kernel anyhow when they don't need it.

    Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship, but security and performance minded sysadmins who reduce installations to what's actually needed.
    • Re:Misleading (Score:5, Informative)

      by shadow42 (996367) on Sunday February 10, 2008 @04:36PM (#22372584)
      I just successfully used this exploit on a Fedora 7 box running 2.6.22.4. A bit out of date, yes, but a great deal of "home users" who are running Fedora, Debian, Ubuntu (especially Ubuntu), etc., either don't know how to compile their own kernel, or don't care enough to try. Not everyone who uses Linux is going to bother compiling a custom kernel in order to fix a problem like this, especially if they don't have the skills of a sysadmin.
      • Re:Misleading (Score:5, Insightful)

        by Anonymous Coward on Sunday February 10, 2008 @04:43PM (#22372674)
        The average home user that's not willing to put in the effort to compile a new kernel is the home user that doesn't have anyone but either themselves, or people with physical access to the machine using it.

        If the only people that have accounts on the machine have physical access to it, this exploit is a lot more work than just opening the box...
      • Re:Misleading (Score:5, Insightful)

        by kitgerrits (1034262) on Sunday February 10, 2008 @05:14PM (#22372962)

        You know, I haven't built my own kernel since 'make menuconfig' was the most advanced method around.
        I got rather tired of picking and choosing what I need, just to get faster boot times.

        That, and any time you need (professional) support for a third-party application, the first thing they ask you is wether you are running a stock kernel.
        I -want- to be able to tell MySQL and RedHat to fight it out amongst themselves if my database does not live up to expectations.
        I have better things to do with my time than to set-up and analyse endless system profiles, straces and stack dumps.

        Grow up, get a real job and see what the real world is like.
        You'll find that you no longer have the time to check SANS and packetstorm every day, just to see if your system is secure, spend days just to get that library to compile and then see the entire system go out the window, because it cannot be maintained (because you have be re-assigned to another project).
        • Re:Misleading (Score:5, Insightful)

          by Penguinisto (415985) on Sunday February 10, 2008 @07:30PM (#22374186) Journal

          You'll find that you no longer have the time to check SANS and packetstorm every day

          Dunno about you, but it's my job to (among other things) keep abreast of emerging security issues, then decide on their severity and priority. A quickie scan of SANS ISC is just as much a morning habit to me as log reviews and sucking down the morning caffeinated liquid.

          Shit, man... a sysadmin who doesn't check at least some source of leading-edge security news daily is IMHO either incompetent or lazy, and tend to be the ones who look really stupid once they get blindsided by a compromise.

          I'd much rather be chided for pushing something off by a few minutes, than to have to explain to my boss and his peers why I didn't know about XYZ exploit, and more importantly, why I didn't do anything to prevent it from chowing down on the production servers...

          (and no, I don't run Gentoo, and I avoid recompiling any kernel unless absolutely necessary).

          /P

    • Re:Misleading (Score:5, Insightful)

      by Unoti (731964) on Sunday February 10, 2008 @04:41PM (#22372636) Journal

      Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship
      I suppose. But honestly, not everybody really needs a sysadmin that's going to diddle around for weeks and compile kernels just to set up a mail server and samba, for example. For most things, I'd rather have someone who just gets the work done rather than goofing off compiling kernels, installing ReiserFS and doing god knows what else other than things that really matter. Sure, there's a place for all that, but honestly most environments don't require it.
      • by lakeland (218447)
        I agree. It is the job of the vendor to know what about this sort of thing and turn off the features that I won't ever want so that the sysadmin doesn't have to concern himself with such details.

        Saying 'it is the user's problem' just isn't good enough. It is everyone's problem, and if everybody tries to fix it then maybe it will go away.
    • by fo0bar (261207) on Sunday February 10, 2008 @04:42PM (#22372666)

      This is not an universal problem. It only occurs for those kernels with a specific function compiled in that most installations won't need, and which halfway decent sysadmins won't have as part of the kernel anyhow when they don't need it.

      Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship, but security and performance minded sysadmins who reduce installations to what's actually needed.

      Which reminds me, have you done your emerge -abuop6QvvvvVVvVVxz world yet today?
    • Re:Misleading (Score:5, Insightful)

      by Kjella (173770) on Sunday February 10, 2008 @04:57PM (#22372816) Homepage
      You've got to be kidding me right? Like every sysadmin out there is supposed to know about every feature he doesn't use? Most of the time if you compile out something you'll end up breaking something you do want because you don't understand the internal kernel dependencies or what this really means in terms of functionality. Don't forget I now expect you on duty 24/7 to compile new kernels whenever there's a kernel patch available, particularly when you're sick and or vacation and whoever is filling in for you only knows apt-get/yum/whatever. Anyone that spent that much time on managing a Linux server would probably be fired because he'd be less efficient than a Windows server and an MSCE.
    • by BasharTeg (71923) on Sunday February 10, 2008 @06:18PM (#22373522) Homepage
      Quick, cue the Linux apologists! Damage control! Spin it! Only noobs and bad administrators would be affected!
    • Re:Misleading (Score:4, Insightful)

      by Actually, I do RTFA (1058596) on Sunday February 10, 2008 @06:34PM (#22373646)

      This is not an universal problem. It only occurs for those kernels with a specific function compiled in that most installations won't need, and which halfway decent sysadmins won't have as part of the kernel anyhow when they don't need it.

      Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship, but security and performance minded sysadmins who reduce installations to what's actually needed.

      Suppose there is a bug in Windows (stretch your imagination to include that possibility) that is part of one of the unpopular services on by default. No one on /. would excuse it because the user (or their sysadmin) should have disabled that service.

      Also, options should never, as a principle, cause security holes.

    • This is incorrect (Score:5, Informative)

      by bconway (63464) on Sunday February 10, 2008 @06:52PM (#22373834) Homepage
      Vmsplice is part of the core kernel, it is not a configuration option. It is used all over the place.

    • Re: (Score:3, Interesting)

      by iabervon (1971)
      Using vmsplice() in ordinary applications should improve system performance under load when appropriate (when you send full pages of generated data to a network connection, the kernel won't have to copy the pages, it can DMA straight to the NIC, saving work and cache space). So it's quite possible that distros would ship binaries that use vmsplice() if their default kernels support it, and it would be a performance hit to disable it. I don't know if any significant programs actually use vmsplice() yet, but
  • by ZorbaTHut (126196) on Sunday February 10, 2008 @04:32PM (#22372522) Homepage
    "But see, Linux sucks! It has holes just like Windows does!"

    The difference is that we know about this hole, and can now fix it - I'm just going to bed, and it will no doubt be fixed by the time I wake up. How many Windows security issues are known that haven't been fixed?

    "Oh man, this is why Linux is great! We can find holes, and fix them, like, immediately!"

    Yes, that's a strength of Linux. What I want to know is, what steps will be taken to ensure that bugs of this type - whatever they might be - don't crop up again? One advantage that a large paid organization can have is strict testing requirements - I'm honestly not sure if I believe the Linux kernel is held to the strong standards that a commercial kernel theoretically could be.

    The existence of this bug is a failure on Linux's part. There's no way to get around that. Many mistakes were made, from the original code or design decision that caused this bug all the way up to it not being found until now. The bug will be fixed rapidly - but the process that let this bug be released needs to be looked at, casually at the very least, to figure out if there's a way to stop this class of error from ever happening again. (Whatever class of error it ends up being - I don't pretend to know.)
    • by RonnyJ (651856) on Sunday February 10, 2008 @04:42PM (#22372662)

      The difference is that we know about this hole, and can now fix it
      We know about it now, but how long have some other people known about it? There's this quote from the code:

      This is quite old code and I had to rewrite it to even compile.

      • by QuantumG (50515) <qg@biodome.org> on Sunday February 10, 2008 @06:46PM (#22373766) Homepage Journal
        Yeah, this is an example of one of the millions of Linux kernel holes there are out there. Every now and then, a blackhat gets a job and wants to impress his employer so he pulls out some of his old code and polishes it up. You can tell when it happens because they are so childish that they make the exploit trivial to demonstrate and distribute it far and wide. And you just know that every blackhat who had a variant of this exploit in their personal collection are like "well thanks asshole, now I've got one less Linux kernel exploit.. bastard."
    • Re: (Score:3, Insightful)

      what steps will be taken to ensure that bugs of this type - whatever they might be - don't crop up again?

      All code in the kernel goes through a fairly exhaustive review process to the point where the major developers, like Linus, don't write code much, just review what's already been put in. If you look at the number of linux kernel exploits over the past year, you'll see that there's not a whole bunch (this is the only one I've heard of). Whether it's as good as a commercial, proprietary product, I don't know. But I do know that it's good enough to get the job done well.

  • Works for me too (Score:3, Insightful)

    by etymxris (121288) on Sunday February 10, 2008 @04:36PM (#22372588)
    Just tested on Suse x86_64 10.3, ran as local user and it dropped me into root.

    Linux opteron 2.6.22.16-0.2-default #1 SMP 2008/02/01 19:36:55 UTC x86_64 x86_64 x86_64 GNU/Linux
  • by the_humeister (922869) on Sunday February 10, 2008 @04:44PM (#22372684)
    The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?
    • Re: (Score:3, Informative)

      by cnettel (836611)
      As it's all about VM handling, I'm not sure, maybe some platform might give a panic, maybe some will use a different codepath, but it seems to be high-level enough that it is common code for all architectures. However, the only parts that are specific for x86 and x64 in the actual exploit are really the exploit code that's called within the kernel. As it is inline assembler and calling-convention specific, one would need a separate set for each platform. This is just like a user-space buffer overflow needs
    • Re: (Score:3, Funny)

      by Zoxed (676559)
      > The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?

      I heard that the Debian Architecture group are working through the night to ensure it will work on *all* of their supported platforms. Should be on your favourite mirror by Monday lunchtime !!
    • Re: (Score:3, Informative)

      The POC code needs to have different alignments for x86 and x86_64 but that in itself does not mean that the same concept could not be used to break other architectures, (eg. ARM which probably runs the majority of Linux systems out there... all the phones etc).

      What is important is whether the explotable code is being run. This is only relevant to VMs. Very few Linux phones etc will be using VMs and probably none are using this explotable architecture.

  • Funny comments :) (Score:5, Informative)

    by K. S. Kyosuke (729550) on Sunday February 10, 2008 @04:49PM (#22372734)
    There are some pretty funny comments in the source code, regrettably, most people won't understand them. Hell, as a Czech, I *am* probably supposed to understand them, if it were not for the obscure north-eastern dialect of Czech that all the rest of our country finds hilarious (and incomprehensible at the same time).

    "Dovalim z knajpy a cumim ze Wojta zas nema co robit, kura." == something like "Just returned from the pub and saw that Wojta [a machine? Or a person? Unclear...] has nothing to do." [The last word might be a Czech expletive with a typo...?]
    "Gizdi, tutaj mate cosyk na hrani, kym aj totok vykeca." == something like "Here's something for you to play with, boys, ..." [last for four words utterly incomprehensible :)]
    "Stejnak je to stare jak cyp a aj jakesyk rozbite." == "Anyway, it's old as hell and somehow broken anyway"

    The style (no way am I able to render *this* in English :)) makes me think that had drunk quite a bit before he wrote these gems. Pity that I don't have a good dictionary of spicy English. I'm just rolling on the floor and seriously laughing. :) Oh, and the exploit works, which is not that *funny*.
  • by FliesLikeABrick (943848) <ryan@u13.net> on Sunday February 10, 2008 @04:51PM (#22372754)
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 [debian.org]

    The workaround posted in a follow-up in that thread works. I had a few vulnerable (tested) machines that I cannot reboot even if a patched kernel is released in the near future. I tried that fix, then tried the exploit again. The exploit no longer worked after using the fix (workaround).

    Those machines were debian x64.

    Ubuntu kernels do not appear to have vmsplice enabled by default.
  • by iamamoose (243231) on Sunday February 10, 2008 @04:59PM (#22372830) Homepage
    Upstream patch for the vulnerability tickled by that specific exploit is here
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44 [kernel.org]

    Red Hat tracking bug (Enterprise Linux 5 is affected, but 4,3, and 2.1 are not)
    https://bugzilla.redhat.com/show_bug.cgi?id=432251 [redhat.com]

    Fedora tracking bug
    https://bugzilla.redhat.com/show_bug.cgi?id=432229 [redhat.com]
  • by FudRucker (866063) on Sunday February 10, 2008 @05:05PM (#22372896)
    is vmsplice part of virtualization found in Device Drivers > Virtualization (and the submenu within the said location)?

    if so then mine is ok as i dont build that in my kernel, if this is something else where can it be found in menuconfig?
  • SELinux? (Score:4, Informative)

    by Rob Riggs (6418) on Sunday February 10, 2008 @05:28PM (#22373084) Homepage Journal
    Well, I can tell you that SELinux (enforcing, targeted) on Fedora 8 was no help in preventing this exploit. Does "strict" make a difference?
  • by Narcocide (102829) on Sunday February 10, 2008 @05:36PM (#22373160) Homepage
    Pardon me for the rookie question - but can anyone tell us which kernel config option enables this so-called vmsplice? I'm no even clear on what its for... if its something I don't need can I disable it through menuconfig or is it something that I'll need a patch to disable?
  • by L. J. Beauregard (111334) on Sunday February 10, 2008 @05:37PM (#22373170)
    The given exploit prints pointers using "%lx". That's wrong, and on x86-64 it will break (pointers are 8 bytes, longs are 4 bytes).

    Every instance of "0x%lx" needs to be replaced by "%p".

    The moral of this story is: Always use gcc -Wall and fraggin' pay attention to the warnings.
    • Re: (Score:3, Funny)

      by Kirth (183)
      Not only there:

      $ gcc -o jessica_biel_naked_in_my_bed jessica_biel_naked_in_my_bed.c
      jessica_biel_naked_in_my_bed.c:138:2: error: #error "unsupported arch"
      jessica_biel_naked_in_my_bed.c: In function 'kernel_code':
      jessica_biel_naked_in_my_bed.c:159: warning: initialization makes pointer from integer without a cast
      jessica_biel_naked_in_my_bed.c: In function 'main':
      jessica_biel_naked_in_my_bed.c:211: error: 'PAGE_SIZE' undeclared (first use in this function)
      jessica_biel_naked_in_my_bed.c:211: error: (Each undecl
    • Re: (Score:3, Informative)

      by Sinical (14215)
      No, only Windows uses the retarded long/4 pointer/8 on 64-bit. Linux correctly has 8 byte longs and pointers for x86_64.

      #include

      int
      main(int argc, char *argv[])
      {
              printf("%lu %lu\n", sizeof(long), sizeof(void *));
              return 0;
      }

      $ gcc -Wall test.c -o test
      $ ./test
      8 8

      I agree that %p would be the better choice, but using '%lx' should only provoke warnings on a 32-bit distro.
  • by bcrowell (177657) on Sunday February 10, 2008 @05:54PM (#22373338) Homepage

    It seems to me that slashdot's system for filtering submissions is doing a very poor job these days with stories about security bugs.

    Within the last day or two, we've had the following:

    1. Adobe PDF Exploits In the Wild [slashdot.org] - IMO this was not sufficiently well thought out to be useful. There has been a long series of problems with AR related to the fact that it allows javascript in pdf files to be executed, and that leads both to privacy problems (authors can track readers) and security problems (buffer overflows). But the article didn't specify whether it was such a problem. If it is such a problem, then the correct solution is to disable js in AR. In fact I'd already done that in AR 7, but if I'd blindly followed the advice from the article, here's what would have happened. I would have just upgraded to AR 8 and assumed the problem was fixed. But upgrading to AR 8 reenabled js, so in fact I'd be less secure than I'd been before.
    2. Serious Vulnerability In Firefox 2.0.0.12 [slashdot.org] -- Turns out to be FUD.
    3. OpenBSD Will Not Fix PRNG Weakness [slashdot.org] -- Possibly of interest to openbsd users, but basically what seems to be happening here is that each BSD's maintainers are making their own judgments about how serious the problem is, and the seriousness of the problem is a complicated and controversial question.
    4. Linux Kernel 2.6 Local Root Exploit [slashdot.org] -- The summary makes it sound as though this affects Ubuntu, but later on we get this post [slashdot.org] pointing out that it doesn't affect a default install of Ubuntu.

    This is really getting to be a Boy Who Cried Wolf thing.

  • Just fixed it. (Score:3, Interesting)

    by nagora (177841) on Sunday February 10, 2008 @05:56PM (#22373354)
    Read the bug, ran Vi, fixed exploit in Try that next time your Windows machine has an exploit.

    That's why I use an open-source OS. I can fix it when it breaks.

    TWW

  • by brassman (112558) on Sunday February 10, 2008 @09:20PM (#22374904) Homepage
    So far it's come up with "function not implemented" on all my Ubuntu Dapper LTS servers, which means most of my machines, but it did come up "Exploit gone!" on my 7.10 X64 and a couple of Debian 4.0 boxes.

    Note that if you compile disable-vmsplice-if-exploitable.c on an X86 box you'll need to compile it again for any X86-64 boxes you have.

  • by gringer (252588) on Monday February 11, 2008 @01:57AM (#22376474)
    From what this looks like (given the "old code" comments, and timing of the release of exploit code), I'd say that someone realised that their pet root exploit was being patched in the current kernel (2.6.24.1 [kernel.org]), and wanted to have a final go at increasing the impact of the exploit before it was snubbed out. I find it hard to believe that, coincidentally, they just happened to post this exploit on milw0rm the day after the change appeared in the kernel.

    Poor form, but I guess it has at least made a few more people aware of the severity of the issue.
  • by Toreo asesino (951231) on Monday February 11, 2008 @04:34AM (#22377064) Journal
    ...I have a question for you. I 100% agree this is an advantage of open-source than closed-source software will never have, ever. You've got me on that one, but my immediate thought was "ok, how much would I like to change my own kernel in production systems? About 0% thank-you-very-much".

    I mean, hacking stuff in and out of a production system kernel; surely that's a process that would require months of intensive regression testing, etc, etc? I mean, I doubt there are people that know the kernel well enough to do such changes for their own systems, but really, what percentage of you guys honestly and confidently can say "Yeah, let me just fix that for us" knowing your job is on the line if your systems crash around you.

    This isn't a troll, this is an honest question.
  • by Spoke (6112) on Monday February 11, 2008 @03:04PM (#22381856)
    This local root exploit is very likely to be the one used to infect servers reference in previous Slashdot article Mystery Malware Affecting Linux/Apache Web Servers [slashdot.org].

    It seems pretty clear that people are using other remote vulnerabilities to gain local user access and then using this local root exploit to install their "malware".

    Get those boxes updated as quickly as possible, folks!

Can't open /usr/fortunes. Lid stuck on cookie jar.

Working...