- luv-main - luv.asn.au

Re: btrfs :(
by Peter Ross 07 Oct '14

07 Oct '14

From: "James Harper" <james(a)ejbdigital.com.au> > Rsync integration > > Not claimed - no patches yet - Not in kernel yet > > Now that we have code to efficiently find newly updated files, we need to > tie it into tools such as rsync and dirvish. (For bonus points, we can > even allow rsync to use btrfs's builtin checksums and, when a file has > changed, tell rsync _which blocks_ inside that file have changed. Would > need to work with the rsync developers on that one.) > > Update rsync to preserve NOCOW file status. Means: Make rsync work like btrfs send/receive;-) and put filesystem specific code in it. I am not sure whether this is a great idea. Most of the time you will have the same filesystem on both ends. Then you can use zfs/btrfs etc. tools. Or rsync if it's not a COW system. It is more "code polluting" than it's worth I think. And if btrfs send/receive isn't stable there is a good chance to implement an unstable rsync as well. [Slightly polemic: Later assume that rsync is running on btrfs and make it a requirement;-) (See Unix desktops which became Linux/systemd/upstart/udev/dbus/hald.. only.)] Regards Peter

2 1

Re: bash "Shell Shock" vulnerability
by Rohan McLeod 06 Oct '14

06 Oct '14

James Harper wrote: >> NetComm ADSL2+ Router NB6_REV2_16M >> Software Version: 3.65p >> Login name: admin >> Password: admin >> >> And I'm in. It's a shell, but can't tell what. ps shows a 'sh' process running. >> > Actually: > >> ps --help > BusyBox v1.00 (2010.01.12-11:52+0000) multi-call binary > > Usage: ps > > Report process status > > This version of ps accepts no options. > > So... not bash. > > James > thanks , interesting well that's a relief ! regards Rohan McLeod

2 3

Re: bash 4.3.27 available [Was: bash "Shell Shock" vulnerability]
by Douglas Ray 03 Oct '14

03 Oct '14

On 2/10/14 8:42 AM, Sam Varghese wrote: > Fixes for older versions of OS X are available here: > > http://tenfourfox.blogspot.com.au/2014/09/bashing-bash-one-more-time-update… > > Sam > _______________________________________________ > luv-main mailing list > luv-main(a)luv.asn.au > http://lists.luv.asn.au/listinfo/luv-main > That claims to be an update for CVE-2014-7186 CVE-2014-7187 The version number "4.3.28" is unofficial (not on savannah.gnu.org at time of writing). The two CVEs cite http://openwall.com/lists/oss-security/2014/09/25/32 http://openwall.com/lists/oss-security/2014/09/26/2 http://openwall.com/lists/oss-security/2014/09/28/10 for example bug demo, patches and discussion. Those discussions note that these "out by one" bugs are not remotely accessible in the current (official) 4.3.27. Douglas

1 1

Re: bash 4.3.27 available [Was: bash "Shell Shock" vulnerability]
by Andrew McGlashan 02 Oct '14

02 Oct '14

On 2/10/2014 8:42 AM, Sam Varghese wrote: > Fixes for older versions of OS X are available here: > > http://tenfourfox.blogspot.com.au/2014/09/bashing-bash-one-more-time-update… Partial fixes..... IT IS NOT FIXED. This is so disappointing, how bad is Apple, almost as pathetic as other major vendors such as Cisco and Juniper doing "emergency" patches at long last. Cheers A.

2 2

bash "Shell Shock" vulnerability
by Douglas Ray 01 Oct '14

01 Oct '14

those of you who haven't been up into the small hours looking at the bash shellshock bug: summarized here: http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/ which gives the following useful test env X="() { :;} ; echo busted" `which bash` -c "echo completed" and claims the bug exists from version 1.13 .. 4.3. It can be exploited with wget, ssh, http... They quote NIST thus: GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. Authentication: Not required to exploit Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service More details, and an http exploit, are in http://seclists.org/oss-sec/2014/q3/650 Anyone on OS-X, it affects their bash, sh, csh, tcsh, zsh, ksh; ie, all the distributed shells. happy days...

9 14

Re: multi monitor hardware / graphics card advice
by h 01 Oct '14

01 Oct '14

On Tue, 30 Sep 2014 09:30:33 +1000 Michael Pope <map7777(a)gmail.com> wrote: > Hello, > On 28/09/14 15:43, h wrote: > > Hi, > > I am sure I have seen a post on (a) newsgroup about this lately, but > > am unable to find it. > > Please excuse me posting what I think I should be able to google - > > but cann't. > > > > I run a desktop opensuse / KDE system and I want to replace my > > existing dual monitor system with a quad monitor system. I am > > looking for information on the linux support for graphics card > > setups which support 4+ monitors. > > > > I am resigned to using either nvidia or radeon with proprietary > > drivers, so would appreciate any advice regarding hardware from > > anyone who has done this sort of thing recently. > > > > > > I run 4 24" screens at 1080p at work on Debian 7 stable using two > Nvidia 1GB GTX 650's and configuring it in good old xorg.conf > included below > > > Section "ServerLayout" > Identifier "TriHead" > Screen 0 "Screen0" 3200 0 > Screen 1 "Screen1" 1280 0 > Screen 2 "Screen2" 5120 0 > Screen 3 "Screen3" LeftOf "Screen1" > InputDevice "Keyboard0" "CoreKeyboard" > InputDevice "Mouse0" "CorePointer" > Option "Xinerama" "1" # Enable xinerama on the whole > EndSection > > Section "InputDevice" > > # generated from default > Identifier "Keyboard0" > Driver "kbd" > EndSection > > Section "InputDevice" > > # generated from default > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/psaux" > Option "Emulate3Buttons" "no" > Option "ZAxisMapping" "4 5" > EndSection > > Section "Monitor" > Identifier "Monitor0" > VendorName "Unknown" > ModelName "BENQ E2400HD" > HorizSync 30.0 - 83.0 > VertRefresh 55.0 - 85.0 > Option "DPMS" > EndSection > > Section "Monitor" > Identifier "Monitor1" > VendorName "Unknown" > ModelName "BENQ M2400HD" > HorizSync 30.0 - 83.0 > VertRefresh 55.0 - 85.0 > Option "DPMS" > EndSection > > Section "Monitor" > Identifier "Monitor2" > VendorName "Unknown" > ModelName "CRT-1" > HorizSync 30.0 - 83.0 > VertRefresh 55.0 - 85.0 > Option "DPMS" > EndSection > > Section "Monitor" > Identifier "Monitor3" > VendorName "Unknown" > ModelName "NVT Novatek 563D" > HorizSync 30.0 - 80.0 > VertRefresh 50.0 - 75.0 > EndSection > > Section "Device" > > # Use lscpi | grep VGA to get the BusID > # Note the Screen numbers > Identifier "Device0" > Driver "nvidia" > VendorName "NVIDIA Corporation" > BoardName "GeForce 8400 GS" > BusID "PCI:3:0:0" > Screen 0 > EndSection > > Section "Device" > > # A device for each screen > Identifier "Device1" > Driver "nvidia" > VendorName "NVIDIA Corporation" > BoardName "GeForce 8400 GS" > BusID "PCI:3:0:0" > Screen 1 > EndSection > > Section "Device" > Identifier "Device2" > Driver "nvidia" > VendorName "NVIDIA Corporation" > BoardName "GeForce 8400 GS" > BusID "PCI:4:0:0" > Screen 0 > EndSection > > Section "Device" > Identifier "Device3" > Driver "nvidia" > VendorName "NVIDIA Corporation" > BoardName "GeForce 8400 GS" > BusID "PCI:4:0:0" > Screen 1 > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Device0" > Monitor "Monitor0" > DefaultDepth 24 > Option "NoLogo" "True" > # Option "DoubleBuffer" "True" > Option "TripleBuffer" "True" > Option "TwinView" "0" > Option "metamodes" "DFP: nvidia-auto-select +0+0" > SubSection "Display" > Depth 24 > EndSubSection > EndSection > > Section "Screen" > Identifier "Screen1" > Device "Device1" > Monitor "Monitor1" > DefaultDepth 24 > Option "TwinView" "0" > Option "metamodes" "CRT: nvidia-auto-select +0+0" > SubSection "Display" > Depth 24 > EndSubSection > EndSection > > Section "Screen" > > # Removed Option "metamodes" "nvidia-auto-select +0+0" > # Removed Option "metamodes" "1920x1080 +0+0" > Identifier "Screen2" > Device "Device2" > Monitor "Monitor2" > DefaultDepth 24 > Option "NoLogo" "True" > # Option "DoubleBuffer" "True" > Option "TripleBuffer" "True" > Option "TwinView" "0" > Option "metamodes" "CRT: 1920x1080 +0+0" > SubSection "Display" > Depth 24 > EndSubSection > EndSection > > Section "Screen" > Identifier "Screen3" > Device "Device3" > Monitor "Monitor3" > DefaultDepth 24 > Option "TwinView" "0" > Option "metamodes" "DFP: 1280x1024 +0+0" > SubSection "Display" > Depth 24 > EndSubSection > EndSection > > It works pretty good. > > > from > Michael > Hi Michael, Thanks for the information. I am not on top of multiple graphics cards. Will have to focus on this. Ta again H --

1 0

Re: bash 'Shell Shock' vulnerability
by Peter Ross 29 Sep '14

29 Sep '14

Hi Hannah, > hi peter. I've tested various builds of busybox ash myself and haven't > found the vuln applies. could you supply some more details? It is a QNAP NAS TS-239 Pro2. > were you testing with the () {} string in an HTTP header? No, the web server does not respond anymore. >> Peter Ross wrote: >>> I have an older QNAP NAS appliance (used for backup) that is vulnerable >>> as well. [~] # x='() { :;}; echo VULNERABLE' bash -c : -sh: bash: command not found [~] # x='() { :;}; echo VULNERABLE' sh -c : VULNERABLE [~] # sh --version GNU bash, version 3.2.0(17)-release (i686-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. [~] # uname -a Linux backup 2.6.30.6 #1 SMP Sat Apr 10 06:48:32 CST 2010 i686 unknown >>> AFAIK Busybox uses ash. [as Wikipedia says] Obviously not his one. It has a lot of symlinks to busybox on /bin but its shell is bash. Maybe I do a re-install of "something". I am not sure at the moment. It only copies directories and files to it on the weekly base with external disks used to back them up permanently (and partially off-site) If I put the disks somewhere else I do not need the box anymore. It was just a handy box already in place before I started here. Regards Peter

1 0

Re: bash "Shell Shock" vulnerability
by Rohan McLeod 28 Sep '14

28 Sep '14

James Harper wrote: >> Just out of curiosity, >> I thought would try out the above test; >> on the CLI interface on my Netcomm NB64W ADSL2+ router; >> (standard issue iPrimus ). Thought there was a reasonable chance it used >> BASH; >> I can TELNET 192.168.1.1 to a login prompt ; >> but the u/n ADMIN password doesn't seem to be the same as that for the >> WEB interface; >> anyone have any suggestions for a default p/w; >> or is iPrimus likely to have just locked the CLI down with no access >> possible ? >> As mentioned nothing urgent; but responses appreciated ! >> regards Rohan McLeod >> > A few routers I've seen use 'admin' as the username in the web console, but 'root' as the username as telnet. What username are you using for telnet? I had been using "admin" in web console (default p/w "admin"); I just tried "root" with p/w 'admin' ,"(enter)" and "NB6Plus4W" drops Telnet; then, NB6PLUS4W , NB6PLUS4W_IPRIMUS and nb6plus drops Telnet thanks anyway James regards Rohan McLeod > > James >

1 0

Re: bash 'Shell Shock' vulnerability
by Peter Ross 27 Sep '14

27 Sep '14

From: "Rohan McLeod" <rhn(a)jeack.com.au> > Any news regarding mobile phones and routers etc ? I have an older QNAP NAS appliance (used for backup) that is vulnerable as well. The web interface died four weeks ago so it seems to be time to retire it anyway;-) AFAIK Busybox uses ash. That should be okay for some appliances. On an Apple, I wonder what breaks if you point sh and bash to ksh (until the fix comes in) Probably not much. Regards Peter

2 3

Re: bash "Shell Shock" vulnerability
by Peter Ross 26 Sep '14

26 Sep '14

From: "Joh Lindley" <joh.lindley(a)dcwest.net.au> >> Is Apple's sh a bash? I thought they are using FreeBSD's userland (FreeBSD's sh is not affected [at least the tests are negative and there >> is no SA]) > It would appear so. > sh-3.2$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable > this is a test You are calling the bash [not /bin/sh] here. It shows that you have a bash installed. Regards Peter

8 7