Bash security flaw

nzdoc
nzdoc
Community Member

I am no computer pro so please excuse the ignorance.

But does this Bash issue affect 1password or is it Mac wide?

http://www.bloomberg.com/news/2014-09-25/u-s-warns-of-security-flaw-affecting-linux-to-mac.html

Thanks

Comments

  • Shellshock is something to be worried about but not really in terms of 1Password based on my readings so far.

    The systems most at risk just now, that is to say the ones that will probably get targeted first are web servers or embedded devices that run mini web servers e.g. routers, NAS devices etc. It requires the use of something called cgi-bin (web servers aren't a speciality of mine) but at that point yeah, a system has the potential to be compromised.

    I've heard mention of bash + open ssh being a possible vector too but that seems to be after somebody has successfully authenticated.

    So where does the average mac user stand? If you're dealing with a fresh installation of Mavericks then I believe OS X won't be running a copy of apache. Prior to Mavericks web sharing was something you could activate at which point it would all depend on the default setup as to how at risk you were. Open a browser and visit http://127.0.0.1 If you get a page that says It works! then apache is running. I know it is on mine but I think that's a leftover from my config in Snow Leopard. Excuse me while I go figure out how to permanently turn it off given the GUI option was removed :-S

  • khad
    khad
    1Password Alumni

    1Password itself is not in anyway affected by the bash bug. We are still checking our servers to see if anything uses bash, but haven't found anything vulnerable yet. Other sites may well be vulnerable and may ask people to change passwords at some point.

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    You ask a great question @nzdoc, and @littlebobbytables‌'s explanation is exactly on target.

    1Password and AgileBits are safe from shellshock (bash bug)

    First let me repeat what @khad‌ pointed out. 1Password itself is in no way affected by this. Furthermore, our own web servers all seem to be safe as nothing external ever leads to an invocation of bash. (Additionally, we've updated bash to a patched version, and we've added extra protections to ensure that bash isn't invoked by anything that could contain externally set input.)

    Where it matters to all of us

    What will happen over the next while is that a bunch of web servers will be broken into. Some other servers may also be broken into. A portion of those breaches will be detected and a portion of those detected breaches will be reported. When those are reported, we will all have to change passwords for those particular sites. The "hard" part all of us, of course, is that probably only a small fraction of those servers that compromised will be reported. So to solution for everyone is use a unique password for each site and service.

    bash is everywhere, but don't panic

    Pretty much all of us are using a vulnerable version of bash, but that doesn't mean that we are vulnerable to attack. I am happily using a vulnerable version of bash right now in another window on my Mac. But because there is no way for an outsider to set an environment variable in my shell, I am not particularly concerned. Of course I will apply the next security update.

    What is a shell

    A shell is a program you are talking to in something like an OS X Terminal window. Mostly it handles what you type in and calls up the command you typed with the arguments you gave. It can do other things like process wildcards like * or ?. So if I use the command

    cat *.bib > ~/Documents/allReferences.bib
    

    The shell knows that the program I want to run is cat. The program cat
    doesn't know anything about handing something like *.bib, which means
    something like "all of the files in the current folder that end with '.bib'".
    cat doesn't know about these shell wildcards (or "globs" as they are
    sometimes called. If you have the files crypto.bib, statistics.bib, and
    coop.bib in the folder in which you type that command, the shell, when it
    actually invokes the cat program, will hand it three arguments, 1: coop.bib,
    2: crypto.bib, and 3 statistics.bib.

    So cat is never seeing the *; the shell is handling that. (Note that the Windows/DOS shell, CMD.EXE, does not do that and individual programs need to be programmed to filename wildcards if you want that behavior.)

    Another, less frequently used wildcard, is ?. It matches a single character in a file name.

    Different shells behave differently

    One of the other things that a shell is responsible for is finding what program to run when you give it a command like the above. It needs to find the program cat. I will skip how that happens.

    But you might be wondering, "does the shell look for the command first and then do the wildcard expansion, or does it do the wildcard expansion first and then look for the command?" Clearly that is a perfectly normal question for any sane person to be asking. So I will answer. Some shells do it one way, and other shells do it the other way.

    In bash

    $ gotta light?
    -bash: gotta: command not found
    

    In tcsh

    % gotta light?
    gotta: No match.
    

    What does all of this stuff about shells have to do with anything?

    I'm not sure yet whether that digression about shells makes any point. It was a lot of work just to
    lead up to the csh "gotta light?" thing.

    Perhaps I will get around to tying all this together, and actually explain the shellshock, but that must wait for a later day. I'm off to see the Piano Guys and need to get family together and fed.

    So. To be continued ...

This discussion has been closed.