Chrome blocking unsafe ports

Blocking “unsafe” ports is something that Google Chrome has done for a while now, but I’ve only just discovered this feature, trying to connect to an internal host via HTTP on a non-standard port:

The error message is slightly misleading as the endpoint isn’t down, it’s just being blocked by Chrome – ERR_UNSAFE_PORT is the crucial clue.

This seemed odd to me, but there’s a great explanation here. In a nutshell, it’s an attempt to prevent Chrome being used as a way to attack potentially vulnerable services. Because many implementations of simple plain-text protocols such as SMTP, FTP and Telnet are very tolerant of errors (i.e. simply ignoring commands that don’t make sense), it may be possible for a malicious or compromised website to trick a user’s browser into sending a specially-crafted HTTP request that contains valid commands in the target protocol.

There is an unofficial list of restricted ports here – in my case, the port’s being blocked as it is one of the ports commonly used for IRC (Internet Relay Chat). On desktop Chrome, there is a workaround that allows you to disable this behaviour on a per-port basis, but as far as I can see, there’s no way to do this on the Android version of Chrome. The only real solution is for developers to avoid using these specific non-standard ports for HTTP (there are plenty of other ports to choose from!)

It’s quite an interesting idea, and while in an ideal world there wouldn’t be any services vulnerable to this sort of attack, we all know the reality is quite different. On balance, I think I’m in favour of Google (and Mozilla, who include similar functionality in Firefox) including this simple protection to help make the Web a safer place.

At the time of writing, Internet Explorer on Windows 10 doesn’t seem to block unsafe ports, but the latest version of Edge (which is based on Chromium) gives the same ERR_UNSAFE_PORT error as Chrome.

CSV Injection

I’ve just been reading about the CSV Injection attack – a new one to me, and somewhat surprising that it exists. The source of the problem seems to be a gap between what the CSV format was originally conceived to be (a flat-file format containing only “safe” alphanumeric data) and how modern applications such as Microsoft Excel and OpenOffice/LibreOffice Calc actually interpret the contents of a CSV file.

Many web applications allow users to download bulk exports in CSV format, and if this attack isn’t mitigated, an attacker can potentially include a malicious formula that could execute an arbitrary command on the user’s machine, or enable data to be exfiltrated. In most cases, the user will be presented with one or more warnings, but normally these are worded such that users are likely to dismiss them because they deem the CSV file to have originated from a “trusted” source.

The mitigation is to ensure that no fields within a CSV file begin with the equals sign (=) or any of the several other characters that may cause a spreadsheet application to interpret the contents as a formula to be executed. Additionally, field separator characters such as comma (,) and semicolon (;) should also be disallowed anywhere within the user input, as these could be used to start a new field to defeat the protection above.

Calling Veracode API with Postman

The Veracode API is new to me, so to get to grips with it I decided to fire up Postman and make a few requests. I was initially unsure where to enter my API ID and secret key, and despite trying a few things I kept getting authorisation errors, because the API uses HMAC authentication which is not directly supported by Postman.

The solution I eventually stumbled across was thankfully simple. You just need to grab the pre-request script from here (thanks to Veracode’s Chris Campbell!) and paste it into the Pre-request Script section of your request tab. Finally, add two variables to the Globals tab: veracodeApiKeyId and veracodeApiKeySecret, paste in your Veracode API ID and secret key respectively, and you should now be able to make a successful API request.

Note that you don’t need to select anything in the Authorization section for this to work (just leave it as No Auth).

Quick way to open a command prompt in the current window

In Windows 10, you can type cmd in the address bar of any File Explorer window, and it’ll open a command prompt with the working directory already set. Much quicker than opening a command prompt the usual way and having to cd to the right directory, especially for long nested paths.

Having used Windows 10 since it first came out, and Windows Vista/7/8/8.1 before it, I was surprised when I recently discovered this trick!

Using Okta Verify with Synopsys

The Synopsys (Cigital) web app officially supports only Google Authenticator, Microsoft Authenticator or Authy for 2FA. However, if you already have Okta Verify installed on your phone, and don’t want to install another authenticator app, you can follow this process.

  1. Log into Synopsys and click your username in the top right
  2. Click 2-Factor Authentication Settings then Edit
  3. Select Google Authenticator
  4. On your phone, open Okta Verify and tap the + icon
  5. Click Organization then Scan a QR code
  6. Scan the Synopsys QR code
  7. Type the resulting 6-digit code and your password into the Synopsys window

Lync 2013 installation breaks Office 2010 interoperability

At work, I maintain an Access 2010 database that interfaces with Word, Excel and Outlook. Recently, Lync 2013 was rolled out across the office, without upgrading the rest of Office. Suddenly all interop calls started failing with “Automation error. Library not registered.” errors.

A bit of digging revealed that the Lync 2013 installation process adds registry entries for the Office 2013 (i.e. version 15) automation libraries, regardless of whether the individual 2013 applications are installed. The solution is to remove the offending registry keys, keeping the version 14 keys in place.

I put together the following .reg file to remove the keys for Outlook, Word and Excel respectively:

Windows Registry Editor Version 5.00

There doesn’t seem to be an official Microsoft solution for this – I previously repairing the Office 2010 installation but this had no effect.


Heatmiser PRT-TS Wi-Fi thermostat not working after firmware update

I recently upgraded my PRT-TS Wi-Fi thermostat firmware from 1.2 to 1.6 and found that although it seemed to be working in every other way, it was no longer firing up my boiler when calling for heat.

This is because the Heatmiser hardware contains two relays (presumably so it can be shared with models that also incorporate hot water control), and thermostats shipped prior to 26th January 2012 (which includes mine) are programmed to use the one on the left for central heating, whereas newer thermostats use the one on the right (PDF link – note that although it specifically mentions 1.3 thermostats, mine was a 1.2 and it had the same issue):

To combat this problem, Heatmiser have two sets of firmware – the “A” set for older thermostats and the “B” set for newer thermostats. Unbeknownst to me, I had received version 1.6b when I should have been sent 1.6a.

There are two options to fix this – either have Heatmiser send out a programmer with the 1.6a firmware, which would take a few days, or – as I did – simply rewire the thermostat as per the corrected wiring diagram. Obviously I recommend that you hire a qualified electrician to do this if you’re not proficient yourself.

Unfortunately it’s not possible to determine which firmware you have been sent until you’ve flashed your thermostat with it, so if you decide to upgrade, I recommend you check the label on the rear of your device and check with Heatmiser that they are sending the correct firmware type (A for the top diagram marked with a cross, B for the middle diagram marked with a tick).

Using a PS3 EyeToy with the Raspberry Pi

Having heard about the new camera driver built into the kernel of the new Raspbian OS image, I decided to have a play, using my PS3 EyeToy camera. The steps below are based on this forum thread, with some changes to reflect my own experience. The Raspberry Pi supports a number of cameras, not just the EyeToy, so if you have a spare one lying around, give it a go.

  1. Install the ‘motion’package:sudo apt-get install motion

    This should automatically install the required ‘ffmpeg’ package – if not you can just do sudo apt-get install ffmpeg.
  2. Edit the config file:

    sudo nano/etc/motion/motion.conf

    To enable daemon mode (so you can run the software in the background without it tying up your terminal):

    daemon on

    To increase the resolution to the maximum supported by the EyeToy, change the following lines:width 640
    height 480

    If you want the stream to be viewable from other computers on the network (rather than just the Pi itself):

    webcam_localhost off

    If you want to change the port on which the stream is served (default 8080) – replace 1234 with the desired port number:

    webcam_port 1234

    By default, the camera will only start capturing images (and video) if it detects motion. If you want to take regular snapshots whether motion is detected or not, you can change the following line (the value is in seconds):

    snapshot_interval 60

    (Press Ctrl+X, Y then Enter to save changes and quit the nano editor)

    There are loads of other things you can do such as enable a basic remote control interface, tweak the JPEG quality, set up regular snapshots (by default, snapshots are taken only when motion is detected), customise the text which is overlaid onto the image and change the location to which images are saved (by default these go into /tmp/motion which is deleted whenever the Pi is rebooted). Just have a browse through the config file which is fairly well-commented and self-explanatory.

  3. Now plug the EyeToy into a USB port on your Pi. The two LEDs (one red, one blue) should illuminate. These are not necessary for webcam use so you may want to cover them with black electrical tape or similar.
  4. Start up ‘motion’ in interactive mode (this is a text-mode app which you can run from the terminal, you don’t need to be in the ‘startx’ GUI:sudo motion -n

    (Without the sudo, I get permission errors which I haven’t yet figured out how to resolve).
  5. Browse to the IP address of your Raspberry Pi on the port you configured earlier (or 8080 if you didn’t change it) in a Web browser. Firefox works fine, but at the time of writing the current stable version of Chrome seems to have a bug with motion JPEG streams, and only shows the first frame. You can work around this by embedding the stream into a simple HTML page, which works fine in Chrome:<img src="" />

    Alternatively you can open the stream in VLC. You can also browse to the feed on the Raspberry Pi itself, but you will have to install Chrome or Firefox on it as the built-in Midori browser doesn’t support MJPEG streams.

  6. Once you are satisfied, press Ctrl+C in the terminal to stop the server. You can then start it up in daemon mode:sudo motion
  7. If you need to stop the daemon, get its process ID:cat /var/run/motion/

    And kill it (replace 12345 with the ID from the above file):sudo kill 12345

    If you want to automate this:

    sudo nano /usr/bin/killmotion

    And type in or paste the following lines:

    sudo kill `cat /var/run/motion/`

    (Again press Ctrl+X, Y then Enter to save changes and quit)

    Finally make the script executable:
    sudo chmod a+x /usr/bin/killmotion

    And whenever you need to stop the motion daemon, just type:

And there you have it – a simple baby monitor, security camera or basis for time-lapse photography!

The files can build up quickly though, particularly if you enable regular snapshots, so make sure you have plenty of space on the SD card you are using.

Unfortunately, like the original poster, I noticed that occasional frames had a strange form of corruption (example), which unfortunately the camera detects as motion (although you can tweak the config file to only trigger after a number of consecutive frames of motion). I suspect this may be due to the Raspberry Pi not providing quite enough power to run the camera stably. A powered USB hub may solve the problem, or more drastically, desoldering the two LEDs. Reducing the resolution back down to 352×288 apparently fixes the problem, but obviously means lower image fidelity.

If you don’t already have an EyeToy or spare webcam, it’s probably best to wait for the official Raspberry Pi camera module. It will plug into a dedicated connector on the board so you’re not hogging a USB port, and will obviously be more stable. The pre-release version uses a 14-megapixel sensor, but it’s likely that a lower resolution sensor will be used in the final release to keep the costs down. A good-quality 720p (just under 1 megapixel) sensor would be nice, 1080p (just over 3 megapixels) even better.

How to set up a web interface for a Heatmiser wi-fi thermostat using a Raspberry Pi

My earlier post on the Heatmiser PRT-TS wi-fi thermostat proved very popular and is the most commented article on this blog. When commenter Rich mentioned the heatmiser-wifi project, a set of Perl scripts that can be installed on a PC or Raspberry Pi to provide a full-featured web interface for the Heatmiser, I just had to give it a go.

Although the project site mentions that it has been tested on Raspberry Pi, I just couldn’t get past one of the steps. A little bit of Googling revealed a possible solution, and it worked. Be warned, the process takes a little while but in my opinion the results are definitely worth it.

Installation of Subversion and the heatmiser-wifi software

To get hold of the software, you have to check it out using the Subversion (SVN) source control system. So the first step is to install SVN:

sudo apt-get install subversion

You can then run the following command to download the heatmiser-wifi software:

svn checkout ~/heatmiser-wifi-read-only

This will create a folder called heatmiser-wifi-read-only in your home directory. If you want to specify a different path, edit the command as appropriate.

Install Perl and essential packages

Check that Perl version 5 is installed by running:

perl -v

This should return some output starting with the following (or similar):

This is perl, v5.10.1 (*) built for arm-linux-gnueabi-thread-multi

If not, install Perl using:

sudo apt-get update
sudo apt-get install perl5

Now you need to install the required packages:

curl -L | perl - --sudo App::cpanminus
sudo cpanm CGI Cwd DBI File::HomeDir Getopt::Std IO::Socket JSON LWP::UserAgent Proc::Daemon Proc::PID::File Time::HiRes
sudo apt-get install libxml-simple-perl
sudo cpanm XML::Simple

This takes a long time, so you may want to have a cup of tea, run a bath or go for a walk!

(Note that the original instructions had the CPAN modules listed on one line, omitting the apt-get before XML::Simple, but this didn’t work for me, hence the change. Also I had trouble getting the standard cpan command to work on the Pi due to its limited hardware, hence using cpanminus instead.)

Test the installation

Run the following command, adjusting the path if necessary, replacing with the actual IP address of your Heatmiser and 1234 with the PIN number:

~/heatmiser-wifi-read-only/bin/ -h -p 1234

You should get some output like this:

Heatmiser PRT version 1.2
Thermostat is ON (heating mode)
Time 2012-07-07 21:45:59
Temperature 23.5 deg C (internal)
Target 17 deg C
Heating is OFF
Feature 01: Temperature format C
Feature 02: Switching differential 1 deg C
Feature 03: Frost protect 1
Feature 04: Frost temperature 15 deg C
Feature 05: Output delay 0 minutes
Feature 06: Comms # n/a
Feature 07: Temperature limit 0 deg C
Feature 08: Sensor selection internal
Feature 09: Floor limit n/a
Feature 10: Optimum start disabled hours
Feature 11: Rate of change 20 minutes / deg C
Feature 12: Program mode 5/2 day
Weekday 1: 07:00 20 deg C
2: 07:30 17 deg C
3: 17:00 20 deg C
4: 21:30 17 deg C
Weekend 1: 09:30 20 deg C
2: 21:30 17 deg C

For the rest of the steps to work, you need to store the IP address and PIN number in a config file. To do this:

sudo nano /etc/heatmiser.conf

Type the following two lines, substituting with your thermostat’s actual IP address, and 1234 with its PIN:

PIN 1234

Press Ctrl+X and type Y to save the file.

You should now be able to run the following command (same as before but without the IP and password, which will now be read from the conf file).


Set up the web interface

Happily the project’s web interface instructions seem to work fine on the Pi without any changes.

I have also set up logging and charting of external temperature (via the Met Office API). Frustratingly, my Met Office API key didn’t work straight away – it kept returning Invalid key please register at via both the script and the “preview data” feature on the Met Office site itself. Also note that it will take up to five minutes for the weather table to start populating, unless you’ve increased the rate in the heatmiser.conf file.

Installing lighttpd web server on Raspberry Pi

I’ve just set up my Raspberry Pi, and managed to get it up and running after a minor panic – I couldn’t find a micro USB cable anywhere in the house, despite apparently owning way more mini USB and USB A-B cables than I’ll ever need. I then remembered that the Kindle comes with a micro USB cable, phew!

As a web developer, one of the first things I thought of doing was installing a web server, and decided to go for lighttpd as it’s designed to be lightweight and efficient, which is just the ticket for the Raspberry Pi and its limited hardware resources.

Installing it was as simple as sudo apt-get install lighttpd – or it should have been! The installation failed with “chown: invalid group: ‘www-data:www-data’. To fix this, I ran two commands:

sudo adduser www-data
sudo addgroup www-data

(The first command probably isn’t necessary, as it returned “adduser: The user `www-data’ already exists.”)

I then re-ran sudo apt-get install lighttpd again and it succeeded.

Update 30/05/2012:
I have since decided to switch to Apache and PHP. After running apt-get remove lighttpd, I just had to run:

apt-get install php5

This installs all the basics. Apache still needs the www-data group and will refuse to start if you haven’t already run sudo addgroup www-data.

If you get 404 errors when trying to install PHP (as I did), run the following commands and try again:

apt-get update
apt-get upgrade