8

I want to be sure that whatever string I pass into the line wpa-ssid "abc" in /etc/network/interfaces won't be used to break out of the configuration.

All I can find in the manual is that \ can be used at the end of a line to continue on the next line.

But what about \" in the middle of a line?

My worries is an SSID something like

A"
up rm -rf /\

Are there any general encoding that can be used for arbitrary characters into the SSID field?

5

In Debian's /etc/network/interfaces (or any other distribution using Debian's ifupdown utility), a backslash-newline sequence is removed, and backslash is not special anywhere else. A double quote character is not special either. The character # starts a comment if it's the first non-whitespace character on a (non-continuation) line. Null bytes are treated as newline characters (I think — the parser uses C strings and has no special handling for null bytes, so they might cause additional mischief).

Configuration lines take the form of an option name followed by a value, separated by whitespace. Leading and trailing whitespace is ignored. Some built-in options further parse the line into words; the value of options to iface always runs to the end of the line.

For example, the line

wpa-ssid  "a  b"  "cd"  

sets the option wpa-ssid to the 12-character string "a  b"  "cd" (internal whitespace is preserved).

WPA Supplicant's ifupdown script strips double quotes at the beginning and at the end of the wpa-ssid configuration string, the line above is equivalent to wpa-ssid a  b"  "cd. This way, you can have leading and trailing whitespace in the SSID.

I can't find a quoting issue in the WPA Supplicant ifupdown scripts, so it looks like anything that ifupdown will produce is safe.

Thus you can allow any string as an SSID to be injected into /etc/network/interfaces, provided that it does not contain any newline or null byte. Add double quotes around the string (if you don't, SSIDs with leading or trailing whitespace, or that end with \, or that begin or end with ", will be mangled).

  • Actually I successfully tried wpa-ssid my ssid. – hultqvist Nov 26 '13 at 9:22
  • @phq - to be clear, you were able to use the line wpa-ssid=my ssid? – slm Nov 26 '13 at 16:48
  • @slm no, /etc/network/interfaces does not use = in its syntax, I tried right now and it does not work with =. – hultqvist Nov 27 '13 at 9:34
  • @phq - but to your point, you were able to give it a SSID with spaces then? my ssid? – slm Nov 27 '13 at 13:00
  • @slm yes SSID with spaces has always worked – hultqvist Nov 27 '13 at 13:54
0

This SO Q&A titled: Is there a standard that defines what is a valid SSID and password? answers some of your questions.

excerpt

Section 7.3.2.1 of the 802.11-2007 specification (http://standards.ieee.org/getieee802/download/802.11-2007.pdf) defines SSIDs.

A valid SSID is 0-32 octets with arbitrary contents. A 0-length SSID indicates the wildcard SSID (in probe request frames for instance).

There's no character set associated with the SSID - a 32-byte string of NUL-bytes is a valid SSID.

This implies:

  • you should never use normal string functions when manipulating generic SSIDs (strcpy() and friends).
  • you should not assume that the SSID is printable when, for instance, logging it to disk

There is also this comment on the answer to the SO question:

There's updated version of standard (http://standards.ieee.org/getieee802/download/802.11-2012.pdf ), which defines SSIDEncoding field. It can be UNSPECIFIED (for arbitrary data) or UTF8.

So I would look to the latest standard for guidance and make sure you can deal with what's legal based on that.

What else?

Additionally I might be inclined to guard my self by normalize a user's input using some form of a URL encoding function (something that would work with SSID's obviously) or simply strip out illegal characters and simply not allow them prior to writing these strings to this file.

Weird characters?

The only issues I could find with strange/special characters related to the interfaces file were these types of bugs that were filed against the debian-installer.

debian-installer asked for my wireless networking information and successfully used it to connect wirelessly to the network. It also wrote my wireless networking information to /etc/network/interfaces. However, the WPA key that I entered contained at least one special character, and debian-installer did not escape or quote the special character(s) in /etc/network/interfaces. The result was that, on reboot, the system hung for a very long time during the boot process as it tried (unsuccessfully) to re-connect to the wireless network. I fixed the problem by simply quoting the WPA key listed in /etc/network/interfaces. This should happen automatically if the key contains special characters.

Also there were these bugs, one related to spaces within the SSID, the others related to the passphrase:

In either cases it would seem that wrapping the strings with double quotes is enough to protect the values for both.

Additional examples

Official docs

Digging through the official documentation I found this bit here:

The official docs show this example:

ap_scan=2
network={
        ssid="test adhoc"
        mode=1
        frequency=2412
        proto=WPA
        key_mgmt=WPA-NONE
        pairwise=NONE
        group=TKIP
        psk="passphrase"
}

So it would appear that spaces are allowed, so long as they're quoted correctly. Also there is this example explaining how to provide a SSID with spaces to the iwconfig tool:

Add the name (ssid) for the network you want to create/join. Use single quotes if there is a space in the name.

   $ sudo iwconfig eth1 essid 'name'

Webconverger

I found this example which looks to be Debian under the hood, so the example may be appropriate to your situation, but it's difficult to tell for sure. I bring it up only because it shows an example of how I would've expected a URI encoding method to be exposed to protect against illegal characters.

excerpt

Example 4 "Spaces in the ESSID", broadcasting essid 'Hopstock Gjestenett', with WPA key uiopzxcv

Please avoid spaces in ESSIDs. In this case we workaround with a encodeURI('Hopstock Gjestenett'), to get the following boot recipe:

   wpa-ssid=Hopstock%20Gjestenett wpa-psk=uiopzxcv

So you might be able to encode the spaces that show up in SSIDs using %20.

SSIDs

Digging even deeper I found this comment from the Wikipedia page on Service set (802.11 network).

Each BSS or ESS is identified by a service set identifier (SSID) - a 1 to 32 byte string. This is normally a human-readable string and thus commonly called the "network name".6 In an IBSS, the SSID is chosen by the client device that starts the network, and broadcasting of the SSID is performed in a pseudo-random order by all devices that are members of the network.

This comment is backed up by this presentation from Blackhat EU 2013, titled: Practical Exploitation Using A Malicious Service Set Identifier (SSID).

excerpt

  • No defined restrictions as to what characters can be used within an SSID (IEEE Std 802.11™-2012)
  • Some limitation based on products
    • Some character limitation (ascii only)
    • Unicode

So technically any character is allowed in an SSID, different implementations such as Windows XP, Windows 7, vs. various Linux versions allow/disallow subsets of characters within SSIDs.

References

  • 1
    Your answer doesn't get to the point: what escaping is available in /etc/network/interfaces? – Gilles 'SO- stop being evil' Nov 25 '13 at 23:46
  • @Gilles - thanks, it was a start earlier today at work, I've added some additional info that I had found but hadn't added to the A then. Mostly bugs related to the escaping of characters for "wpa-ssid" & "wpa-psk". – slm Nov 26 '13 at 1:56
  • I can't say if urlencoding the essid works as a boot parameter but it does not work in the interfaces file. – hultqvist Nov 26 '13 at 9:17
  • @phq - I'm not surprised, this was only an idea, and encoding is generally the way you deal with sanitizing data like this in other applications, quoting it would seem to be the only other option, outside of removing it. – slm Nov 26 '13 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.