« Previous | Next»

La Fonera: Autoupdate to 0.7.1.5

Posted by coldtobi | 15 Oct, 2007, 12:16

"There is something suspicious" 

This is, what I read in the logs, when I recently checked the logs of my fonera. It told me, that there was some answer from the "fon-home-script", thinclient.sh.  

Closer investigations gave the reason for this: fon updated the la-fonera software another time. This time, the hotfix and the changes are both small. The Changelog gave me the first hints what to look for:

Bugs:

[DNS change] DNS queries are properly managed now when the WAN IP address of La Fonera changes.

As I won't upgrade unseen changes, I analyzed the changes, as "DNS-update" sounds a like that could include a fix for that chilli "exploit", using dns as a helper.

Anzeige
 

Changes logged.

Notefully is, that they omitted one version jump: According my logs, there was never an 0.7.1-4 released to the public.

By the way: The package (upgrade.fon) has the md5sum of b196bb8c5308cd689df4325388e9a3d4, if you are curious if we talk about the same version. It contains only four files, which are: 

 /bin/thinclient, /etc/banner  /etc/fon_revision  /etc/init.d/N50chillispot.

As you can see, blind updates are not recommended: Overwriting /bin/thinclient might make you loosing access to the box if fon decides so, as this will reenable unasked-for updates.

But lets look in the details, what have been changed. Just if you are wondering: All diffs are against the "stock" 0.7.1.3 version, without any modifications. Well, the diffs are really diffs: output is the one of "diff -Naur <oldfile> <newfile>".

Lets start with

/bin/thinclient.

--- ../../0.7.1.3/bin/thinclient        2007-03-23 13:02:18.000000000 +0100
+++ bin/thinclient      2007-08-02 17:48:57.000000000 +0200
@@ -28,11 +28,17 @@
 
 MODE=$1
 
+[ `grep thinclient /etc/crontabs/root|wc -l` -eq 0 ] && {
+FIRST=$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 30))
+LAST=$( expr $FIRST + 30;)
+echo  "$FIRST,$LAST * * * * /bin/thinclient cron" >> /etc/crontabs/root
+}
+
 rm -f /tmp/.thinclient.sh
 
 case "$1" in
     cron)
-               sleep "$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 3600))"
+               sleep "$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 60))"
                echo "mode='$MODE' wlmac='$WLMAC' mac='$ETMAC' fonrev='$FONREV' firmware='$FIRMWARE' chillver='$CHILLVER' thclver='$THCLVER' device='$DEVICE'" | ssh -T ${PORT:+ -p $PORT}${KEY:+ -i $KEY} "${USER}@${SERVER}" > /tmp/.thinclient.sh
                ;;
     start)

So, there are two changes: FON is slightly changing the way how to connect to the ssh server.  The old version had a static crontable for the thinclient, executing the script exactly at hour. To load-balance the server, a sleep had been inserted for delaying it up to an hour. 

The first modification in the new version creates a new thinclient-entry in the crontable. But the crontable is different this time: Instead running the client once an hour, it is now ran twice. (You might wonder why this code works, as the crontable is only regenerated if /bin/thinclient is not already in the crontab. Read on, I'll come back on this.)

The second change modifies the part, which is actually executed when the cron job is due. As already told, the old version, the thinclient went first to bed, randomly up to 3600 seconds. Now, this time has been reduced to 60 seconds.

About coding quality: Look at the script: " [ ` grep .. | wc  -l ` -eq 0 ] ". Well,  this was defintily not an *nix-guru. At least, it works. It's just ugly.

/etc/banner and /etc/fon_revision

These files updates only the versions in these files to reflect the changes. So I omitt the diffs here. fon_revision is, by the way, used to determine if the fonera needs an update.

/etc/init.d/N50chillispot 

 --- 0.7.1.5_entpackt/etc/init.d/N50chillispot   2007-07-18 18:04:01.000000000 +0200
+++ ../current/etc/init.d/N50chillispot 2006-09-11 21:55:24.000000000 +0200
@@ -6,7 +6,7 @@
 PID_F=/var/run/chilli.pid
 PID_LOOP_F=/var/run/chilli_loop.pid
 LOG_LOOP_F=/var/log/chilli_loop.log
-LANIP="$(ifconfig "$lan_ifname" | grep inet | awk -F'[: ]+' '{print $4}')"
+WANIP="$(ifconfig "$wan_ifname" | grep inet | awk -F'[: ]+' '{print $4}')"
 MAC=$(ifconfig wifi0 | head -n1 | awk '{print $5}'|sed s/:/-/g)
 MAC=${MAC:-fon}
 LOOP=true
@@ -93,8 +93,8 @@
                /sbin/insmod tun >/dev/null 2>&1
                ifconfig $wifi_ifname 0.0.0.0 # deconfigure the wifi interface
                /usr/sbin/chilli
-                       --dns1="$LANIP"
-                       --dns2="$LANIP"
+                       --dns1="$WANIP"
+                       --dns2="$WANIP"
                        --radiusnasid="$MAC"
                        --dhcpif $wifi_ifname
                        --pidfile=$PID_F
@@ -113,8 +113,8 @@
                /sbin/insmod tun >/dev/null 2>&1
                ifconfig $wifi_ifname 0.0.0.0 # deconfigure the wifi interface
                /usr/sbin/chilli
-                       --dns1="$LANIP"
-                       --dns2="$LANIP"
+                       --dns1="$WANIP"
+                       --dns2="$WANIP"
                        --radiusnasid="$MAC"
                        --dhcpif $wifi_ifname
                        --pidfile=$PID_F

As you can see, they only replaced $LANIP with $WANIP. The purpose is that fixed bug in the changelog: Now they extract the dns information from the right network interfaces: Before they used ath1 (the "private" WLAN interface), now the use eth0. But there is no change visible to me, which will fix the dns issue, making it still possible to open ssh access.

The upgrade script.

This time, only coping the files to the filesystem won't update the La Fonera properly. The reason is, that this time in the upgrade script executes also steps before the file system has been updated: First the thinclient is thrown out of the crontab, then the upgrade performed. The additonal line -- rm /etc/chillispot-fon.init  -- can be ignored: At least my fonera does not have this file. 

The filtering is the missing key, why the modifications in /bin/thinclient actually are working. If this is not done, the crontab would never be modfied, as the script has no glue about the missing modfication.

Upgrade instructions 

The fon-script can be used to upgrade the fonera. However, make sure to backup your changes to the /bin/thinclient. I suggest this procedure: (DISCLAIMER: If you break your fonera, you own both parts. Its all soley on your own risk)

  1.  mv /bin/thinclient /bin/thinclient_bak  
  2. use the ssh-downloaded-update script (will download and install the changes.)
  3. edit the /bin/thinclient to get your changes back. My favourite methode is
    1. vim /bin/thinclient/ to remove all lines that were "original" in the FON-file
    2. cat /bin/thinclient_bak  >>/bin/thinclient
    3. check the changes.

 

Conclusion: Is Big Brother Watching You? 

The current update won't harm, in case of fixing "sshecurity" issues, especiall the use of kolofonium will be still possible. But on the other side, FON failed again to fix a well-known security problem, which could present your local LAN to an mascilious user. 

The introduced changes in the thinclient are potentially capable to find out which users have disabled the automatic upgrades, as the behaviour is now more predictable: The thinclient will now report in at twice the rate, and a particular box will always call in at the very same time.

Honestly, I do not think that that was the purpose for the introduced changes. I think this should just improve the data set, which boxes are currently available. In the old version, it could happen, that the box will report in twice in a relative short time period, as it is pure random. So in worst case, fon would have heard nothing from a box up to close 2 hours. No, the timeout can be reduced to sligthly more than 30 minutes. If it is not reporting in, it is offline or there are network problems.  

La Fonera | Comments (0) | Trackbacks (0)

Related Articles:

0 Comments | "La Fonera: Autoupdate to 0.7.1.5" »

Add comment

 

 This is the ReCaptcha Plugin for Lifetype

Due to German legislation, all comments are moderated. If you get NO error message, your comment is accepted by the system and will be released at the earliest opportunity. Sorry for the inconvenience this might cause.

Inappropiate comments might be edited or not accepted.