FeM

A WiFi client is usually connected to an AccessPoint for WPA-protected network access. When the AccessPoint becomes unreachable for example as the client moved, the client needs to switch over to an other AccessPoint providing the same extended service set (ESSID). This is called roaming.

Roaming involves the following steps:

1. Scanning for an other reachable AccessPoint (Probe)
   
2. Disconnect from the old AP
   
3. Changing the WiFi-channel
   
4. Authentication and Association
   
5. WPA-EAP-Handshake (only for 802.1X)
   
6. 4-way WPA handshake
   
7. Connection is ready again
   

These steps need time and the client is disconnected until he completed them, but there are some options available to speed things up:

Some time ago, we enabled IPv6 on our internal database webserver. The PHP application running bound its sessions to the client IP address. The local clients configured its IPv6 address using IPv6 auto-configuration with privacy-extensions enabled. This lead to IPv6 clients sometimes changing its IPv6 address used with the connection to the web server, so they could no longer use their session and thus were logged off.

The solution was to install SSL client certificates, so clients could reliably be identified even across different IPv6 privacy extension addresses. These client certificates were automatically generated and signed by a local CA using HTML <keygen> and PHPseclib and only served to identify the browser instance.

Now these client certificates started to expire.

As our Firefox users had not cleared the "Remember this decision" flag when choosing their single client certificate to connect with, Firefox 41 continued to connect using an expired certificate. The "auto select client certificate" in Firefox does not do any better, thought. When the server rejects an SSL client certificate with ssl_error_expired_cert_alert, Firefox shows an error message to the user but does not offer him to reselect an other client certificate. So users started to puzzle about how to fix this error. Even installing a renewed client certificate (same subject, issuer and public key) ahead of expiration into Firefox 41 does not help, as that does not remove the old certificate which is still chosen for connecting with.

So the only place to fix this is the server. On server side, the list of accepting CAs could be changed. Though Firefox code looks like in "auto select client certificate" mode this would work, the "use remembered client certificate" lacks any client certificate issuer check. So this does not look promising (see ClientAuthDataRunnable::RunOnTargetThread), though it has not been tested. Next, trying to configure apache 2.4 (Debian Jessie) to accept expired client certificates (while still requesting - at least optionally - one) turns out to be impossibly. There just is no such option. Thought, patching and recompiling apache2 was to be avoided as the server should still be able to install Debian security updates without much manual intervention.

After digging through the source of apache 2.4 mod_ssl, it appears that it is making heavy use of OpenSSL certificate validation routines to check client certificates - including the expiration checks (in contrast to https proxy server certificate validation, where expiration time is checked in mod_ssl itself). Specifically, it uses ssl_callback_SSLVerify with SSL_set_verify to ignore some verification errors already.

LD_PRELOAD is a mechanism to load a shared library early during linking (starting) of an applicaton (like apache2). The linker will the prefer the functions provided by LD_PRELOAD libraries over those libraries indicated by the application itself - so it can be used to hook into library function calls. By writing a specifically crafted LD_PRELOAD library, SSL_set_verify can be hooked and the callback replaced. The new callback will filter out any X509_V_ERR_CERT_HAS_EXPIRED error before passing back control to the original ssl_callback_SSLVerify callback.

LD_PRELOAD can the be configured in /etc/apache2/envvars (used by apache2ctl and thus Debian init scripts) to load the new library.


# mysslverify.c
// gcc -Wall -D_GNU_SOURCE -fPIC -DPIC -shared -ldl -o mysslverify.so mysslverify.c
// use with LD_PRELOAD=/.../mysslverify.so

#include <openssl/ssl.h>
#include <dlfcn.h>

void (*orig_SSL_CTX_set_verify)(SSL_CTX *ctx, int mode, int (*verify_callback)(int, X509_STORE_CTX *)) = NULL;
void (*orig_SSL_set_verify)(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *)) = NULL;
int (*orig_verify_callback)(int, X509_STORE_CTX *) = NULL;

int verify_callback(int ok, X509_STORE_CTX *ctx) {
  if (!ok && X509_STORE_CTX_get_error(ctx) == X509_V_ERR_CERT_HAS_EXPIRED) {
    X509_STORE_CTX_set_error(ctx, X509_V_OK);
    ok = !ok;
  }
  return orig_verify_callback(ok, ctx);
}

void SSL_CTX_set_verify(SSL_CTX *ctx, int mode, int (*cb)(int, X509_STORE_CTX *)) {
  if (orig_verify_callback == NULL) orig_verify_callback = cb;
  if (cb != NULL && cb == orig_verify_callback) cb = verify_callback;
  if (!orig_SSL_CTX_set_verify) orig_SSL_CTX_set_verify = dlsym(RTLD_NEXT, "SSL_CTX_set_verify");
  orig_SSL_CTX_set_verify(ctx, mode, cb);
}

void SSL_set_verify(SSL *s, int mode, int (*cb)(int, X509_STORE_CTX *)) {
  if (orig_verify_callback == NULL) orig_verify_callback = cb;
  if (cb != NULL && cb == orig_verify_callback) cb = verify_callback;
  if (!orig_SSL_set_verify) orig_SSL_set_verify = dlsym(RTLD_NEXT, "SSL_set_verify");
  orig_SSL_set_verify(s, mode, cb);
}


When debugging program crashes, memory misuse debuggers become handy. AddressSanitizer [1] is implemented by the compiler (both gcc and clang support it), where each memory access is first checked against some state information that indicate whether the address is safe to access (e.g. malloc'ed and not freed). The state information is maintained by some library called libasan.so or libsanitizer, and all programms compiled with address sanitizer support need to be linked (statically or dynamically) against it.

To get a program with address sanitizer support compiled in, it needs the following flags:

TARGET_CPPFLAGS += -fsanitize=address -fno-omit-frame-pointer
TARGET_CFLAGS += -fsanitize=address -fno-omit-frame-pointer
TARGET_LDFLAGS += -lasan -fsanitize=address
TARGET_LDFLAGS_C += -lasan -fsanitize=address


So the toolchain (gcc) needs to be compiled with support for compiling for address sanitizer, that is using gcc "--enable-sanitizer" configure argument. The trouble with OpenWRT is that it uses uClibc, so libsanitizer does not compile out of the box against it. Additionally, libasan.so needs to be packed (it depends on libstdcpp) and packets compiled with address sanitizer need to depend on libasan, thought that was not that much of an issue.

So how can one enable libsanitizer with uclibc? The following steps are for toolchain gcc 4.8, gcc 4.9 will be more difficult because its extra features result in more (conflicting) dependencies.

1. patch gcc 4.8 to avoid using __libc_malloc as uClibc does not provide this [2]
   
2. change OpenWRT toolchain Makefiles to enable sanitizer support for gcc
   
diff --git a/toolchain/gcc/final/Makefile b/toolchain/gcc/final/Makefile
index 3fb5ccf..4fae52f 100644
--- a/toolchain/gcc/final/Makefile
+++ b/toolchain/gcc/final/Makefile
@@ -4,7 +4,7 @@ include ../common.mk

GCC_CONFIGURE += \
--with-headers=$(TOOLCHAIN_DIR)/include \
- --disable-libsanitizer \
+ --enable-libsanitizer \
--enable-languages=$(TARGET_LANGUAGES) \
--enable-shared \
--enable-threads \
@@ -58,7 +58,7 @@ endef

define Host/Install
$(CleanupToolchain)
- $(_SINGLE)$(GCC_MAKE) -C $(GCC_BUILD_DIR) install
+ $(_SINGLE)$(GCC_MAKE) -C $(GCC_BUILD_DIR) install install-target-libsanitizer
# Set up the symlinks to enable lying about target name.
set -e; \
(cd $(TOOLCHAIN_DIR); \
diff --git a/toolchain/gcc/minimal/Makefile b/toolchain/gcc/minimal/Makefile
index 0344e1a..e14f64a 100644
--- a/toolchain/gcc/minimal/Makefile
+++ b/toolchain/gcc/minimal/Makefile
@@ -6,7 +6,7 @@ GCC_CONFIGURE += \
--with-newlib \
--without-headers \
--enable-languages=c \
- --disable-libsanitizer \
+ --enable-libsanitizer \
--disable-libssp \
--disable-shared \
--disable-threads
@@ -30,11 +30,11 @@ define Host/Prepare
endef

define Host/Compile
- +$(GCC_MAKE) $(HOST_JOBS) -C $(GCC_BUILD_DIR) all-gcc all-target-libgcc
+ +$(GCC_MAKE) $(HOST_JOBS) -C $(GCC_BUILD_DIR) all-gcc all-target-libgcc all-target-libsanitizer
endef

define Host/Install
- $(GCC_MAKE) -C $(GCC_BUILD_DIR) install-gcc install-target-libgcc
+ $(GCC_MAKE) -C $(GCC_BUILD_DIR) install-gcc install-target-libgcc install-target-libsanitizer
endef

define Host/Clean

   
3. fix uClibc to pass the sixth syscall argument to the kernel on powerpc (as my platform is powerpc) (or you will get "failed to mmap" errors)
   
--- uClibc-0.9.33.2/libc/sysdeps/linux/powerpc/syscall.S 2015-05-14 09:24:29.299815401 +0200
+++ uClibc-0.9.33.2/libc/sysdeps/linux/powerpc/syscall.S 2015-05-14 09:24:41.187991584 +0200
@@ -30,6 +30,7 @@
mr 5,6
mr 6,7
mr 7,8
+ mr 8,9
sc
bnslr;

   
4. add libasan to OpenWRT packages
   
diff --git a/package/libs/toolchain/Makefile b/package/libs/toolchain/Makefile
index 42b9935..aad3d3c 100644
--- a/package/libs/toolchain/Makefile
+++ b/package/libs/toolchain/Makefile
@@ -133,6 +133,34 @@ define Package/libstdcpp/config
endef


+define Package/libasan
+$(call Package/gcc/Default)
+ NAME:=libasan
+ TITLE:=GNU Standard ASAN Library v3
+ DEPENDS=+libstdcpp
+endef
+
+define Package/libasan/config
+ menu "Configuration"
+ depends on EXTERNAL_TOOLCHAIN && PACKAGE_libasan
+
+ config LIBASAN_ROOT_DIR
+ string
+ prompt "libasan shared library base directory"
+ depends on EXTERNAL_TOOLCHAIN && PACKAGE_libasan
+ default TOOLCHAIN_ROOT if !NATIVE_TOOLCHAIN
+ default "/" if NATIVE_TOOLCHAIN
+
+ config LIBASAN_FILE_SPEC
+ string
+ prompt "libasan shared library files (use wildcards)"
+ depends on EXTERNAL_TOOLCHAIN && PACKAGE_libasan
+ default "./lib/libasan.so.*"
+
+ endmenu
+endef
+
+
define Package/libc/Default
SECTION:=libs
CATEGORY:=Base system
@@ -420,6 +448,11 @@ ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),)
$(CP) $(TOOLCHAIN_DIR)/lib/libstdc++.so. $(1)/usr/lib/
endef

+ define Package/libasan/install
+ $(INSTALL_DIR) $(1)/usr/lib
+ $(CP) $(TOOLCHAIN_DIR)/lib/libasan.so. $(1)/usr/lib/
+ endef
+
use_libutil=$(if $(CONFIG_EGLIBC_OPTION_EGLIBC_UTMP),libutil)
use_libnsl=$(if $(CONFIG_EGLIBC_OPTION_EGLIBC_NIS),libnsl)
use_nsswitch=$(if $(CONFIG_EGLIBC_OPTION_EGLIBC_NSSWITCH),libnss_dns libnss_files)
@@ -568,6 +601,15 @@ else
exit 0
endef

+ define Package/libasan/install
+ for file in $(call qstrip,$(CONFIG_LIBASAN_FILE_SPEC)); do \
+ dir=`dirname $$$$file` ; \
+ $(INSTALL_DIR) $(1)/$$$$dir ; \
+ $(CP) $(call qstrip,$(CONFIG_LIBASAN_ROOT_DIR))/$$$$file $(1)/$$$$dir/ ; \
+ done ; \
+ exit 0
+ endef
+
define Package/libstdcpp/install
for file in $(call qstrip,$(CONFIG_LIBSTDCPP_FILE_SPEC)); do \
dir=`dirname $$$$file` ; \
@@ -638,6 +680,7 @@ $(eval $(call BuildPackage,libgcc))
$(eval $(call BuildPackage,libatomic))
$(eval $(call BuildPackage,libssp))
$(eval $(call BuildPackage,libstdcpp))
+$(eval $(call BuildPackage,libasan))
$(eval $(call BuildPackage,libpthread))
$(eval $(call BuildPackage,libthread-db))
$(eval $(call BuildPackage,librt))

   
5. fix malloc being called from within malloc replacement function indirectly due to stack unwinding needing it (similar to [3], but that patch does apply to gcc 4.8 ). This patch might lose backtraces when used with threaded applications.
   
--- gcc-linaro-4.8-2014.04/libsanitizer/sanitizer_common/sanitizer_linux.cc.orig 2015-05-15 09:50:10.190769407 +0200
+++ gcc-linaro-4.8-2014.04/libsanitizer/sanitizer_common/sanitizer_linux.cc 2015-05-15 09:50:52.503376258 +0200
@@ -494,9 +494,13 @@
}

void StackTrace::SlowUnwindStack(uptr pc, uptr max_depth) {
+ static int nested = 0;
this->size = 0;
+ if (nested)
+ max_depth = 0;
this->max_size = max_depth;
if (max_depth > 1) {
+ nested++;
_Unwind_Backtrace(Unwind_Trace, this);
// We need to pop a few frames so that pc is on top.
// trace[0] belongs to the current function so we always pop it.
@@ -507,6 +511,7 @@
else if (size > 4 && MatchPc(pc, trace[4])) to_pop = 4;
else if (size > 5 && MatchPc(pc, trace[5])) to_pop = 5;
this->PopStackFrames(to_pop);
+ nested--;
}
this->trace[0] = pc;
}

   
6. fix register usage in asan (or you'll see all kinds of false-positive errors): [3] (the changelog part is not required)
   
7. recompile OpenWRT from the scratch or atleast
   
make toolchain/gcc/final/clean
make toolchain/gcc/final/install
make toolchain/uClibc/clean
make toolchain/uClibc/install

   
8. change and possibly recompile the packages you need address sanitizer support with (mind the libraries!)
   

When recompiling uClibc, make sure that all copies of libuClibc-0.9.33.2.so got updated, or you might end up with a copy that does not have the syscall function fixed. If not fixed, when stracing, you will see the last argument of mmap2 to be 0xffffffff or alike; and program startup will fail with "mmap failed".

With this, I finally got hostapd on an embedded device running and found the memory corruption bug I introduced by accident.

[1] http://en.wikipedia.org/wiki/AddressSanitizer
[2] http://patchwork.ozlabs.org/patch/233933/
[3] https://github.com/gcc-mirror/gcc/commit/a15fa55a4a13bde63a86422bba672b3af8232a31

Nachdem ein Teil der AccessPoints nun geliefert ist, schreitet der Ausbau voran.

Aktuell ist Haus P vollständig, im Haus I sind noch 2, im Haus H noch 4 und im Haus K noch 23 AccessPoints zu installieren; diese sind auch als Nächstes für den Ausbau eingeplant.

Voraussetzung für den Ausbau mit FeM-WLAN sind freie LAN-Kabel und die Unterstützung von Strom-über-LAN (POE). Im Haus A, C, D, E, Q, CJD ist POE verfügbar, allerdings fehlen noch Kabel. Im Haus B, L und N sind Kabel verfügbar, aber noch kein POE - was sich jedoch nachrüsten ließe.

Daneben gibt es an ausgewählten Standorten (beispw. in den Clubs) bereits jetzt FeM-WLAN zu empfangen.

Wenn du also Interesse hast, den Ausbau beispw. in deinem Block zu beschleunigen, dann komm doch einfach mal vorbei.

Donnerstags in ungeraden Wochen um 20:30 Uhr im Haus L, Eingang 6d, im Keller.

Wie ermittelt man eigentlich aus dem Browser heraus, wie schnell gerade das WLAN ist? Diese Frage stellte sich uns, bei dem Versuch, über eine Webseite den Nutzern die Möglichkeit einzuräumen, uns Feedback zur FeM-WLAN Qualität und -Empfang zu geben.

Der WLAN-Ausbau auf dem Campus schreitet voran. Nach und nach werden die AccessPoints geliefert, die Software installiert und die Geräte verbaut.

Dafür sind wir auf eure Mithilfe angewiesen, da die AccessPoints in den Fluren der WGs installiert werden sollen! Wir werden euch daher in den kommenden Zeit bei Bedarf persönlich ansprechen oder anschreiben, sofern in eurer WG ein AccessPoint installiert werden soll.

Derzeit ist das Haus I an der Reihe. Außerdem gibt es in den Studentenclubs, im Keller des Haus A, im Interclub, im Haus P, im FeM-Office sowie bei einigen Administratoren bereits FeM-WLAN.

Die Authorisierung von Anfragen einloggter Nutzer erfolgt in Webanwendungen sehr oft mit Hilfe von Sitzungscookies.

Kann ein Angreifer ein solches Ausspionieren oder erraten, kann er oft die gesamte Sitzung des eingeloggten Nutzers übernehmen und mit seinen Rechten die Webanwendung / Webseite nutzen.

Derartige Angriffe sind in der Vergangenheiten manigfaltig dokumentiert worden. Ein erster Schritt zum Schutz der Sitzungscookies ist die Nutzung von HTTPS.

Die Nutzung von HTTPS reicht jedoch nicht in allen Fällen aus, wie die BEAST, CRIME und BREACH Angriffe zeigen.

Angenommen, man möchte einen LAN-Anschluss bereit stellen, an welchem sich die Nutzer zunächst mit 802.1X authentifizieren müssen, und danach das passende VLAN bereit gestellt bekommen.
Bei der FeM bespielsweise an den APs für Veranstaltungsstreaming.

Die dafür notwendigen Änderungen am Linux-Kernel, an Bibliotheken und am hostapd finden sich nun auf http://git.fem.tu-ilmenau.de

• libnl: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/libs/libnl/patches/0001-macvlan-add-support-for-source-mode.patch;h=4572e10f54bf809bdd3659bcda220d81dfbff63e;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• iproute2: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/network/utils/iproute2/patches/999-iproute2-macvlan-add-source-mode.patch;h=0abcb39925efa12485fe0df2b5535eebbf6ab89c;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• linux kernel: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=target/linux/generic/patches-3.10/998-add-macvlan-source-mode.diff;h=3862d393f19fd1b5e342024b8f15d7ca4bf9c0d2;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• hostapd: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/network/services/hostapd/patches/905-add-wireng-vlan-driver.diff;h=d34519710e069eff9e86f3a4abda63f12217356f;hb=2ba3eff2d9ed3e573055bf8b1835b0da9265e7d1
  

Einrichtung im hostapd:

interface=eth2
driver=wired-ng

ieee8021x=1

# RADIUS
auth_server_addr=1.2.3.4
auth_server_shared_secret=MySharedPasswd

# VLAN
dynamic_vlan=2
vlan_tagged_interface=vpnuplink
vlan_bridge=brvlan


Die Deauthentifizierung erfolgt bei timeout oder wenn der Port offline geht.

Seit einigen Jahren ist der sogenannte DNS-"ReBind"-Angriff bekannt. Dabei wird ausgenutzt, dass im DNS unerwartete IP-Adressen eingetragen sind, und kann dazu genutzt werden, beispielsweise eine Firewall oder andere Zugriffskontroll-Maßnahmen zu umgehen. Datails dazu unter [1] oder [2] und anderen.

In der Folge kann es ratsam sein, dagegen schützende Filter im lokalen DNS Server einzurichten. Eine andere Möglichkeit besteht darin, den Filter im Browser einzurichten - beispielsweise mit der Firefox-Erweiterung NoScript und ihrem Feature Application Boundary Enforcer (ABE).

WPA-PSK wird nur für Heimnutzer empfohlen, da alle Geräte an einem AccessPoint das gleiche Passwort verwenden - was im Kontext großer Organisationen jedoch nur unzureichende Sicherheit bietet.

• So kann jeder Teilnehmer einen eigenen AccessPoint aufsetzen, welcher mit allen anderen Geräten eine Verbindung aufbaut (AP Impersonation), da jeder Teilnehmer das gemeinsame Geheimnis kennt. Dies kann zur Überwachung und Man-In-The-Middle Angriffen genutzt werden.


• Weiterhin muss bei Änderungen der Gruppe der Berechtigten allen Teilnehmern ein neues Passwort mitgeteilt werden


• und es kann über die verwendeten Zugangsdaten nicht mehr rekonstruiert werden, welcher Nutzer ein bösartiges Gerät genutzt hat.

Für größere Organisationen wird daher WPA-EAP empfohlen, welches neben unbestreitbaren Vorteilen jedoch auch Nachteile hat. Der größte Nachteil ist in meinen Augen, dass beim Einsatz von TTLS-PAP Passwörter ausspioniert werden können sowie AP-Impersonation möglich ist, sofern auf dem Gerät das CA-Zertifikat nicht eingerichtet wurde (oder der Angreifer ein gültiges Server-Zertifikat besitzt). Der Einsatz von TTLS empfiehlt sich jedoch, wenn die Nutzeridentität gegenüber dem AP-Netzbetreiber anonym bleiben soll.

Weniger bekannt ist die Möglichkeit, WPA-PSK mit geräte-spezifischen Zugangsdaten zu betreiben. Dabei wird auf dem AccessPoint jedem Client ein eigenes Passwort zugeordnet, die Identifikation erfolgt anhand der MAC-Adresse des Gerätes. Eine solche Konfiguration wird beispielsweise von hostapd unterstützt, welches in neueren Versionen die WPA-Passphrase auch mittels RADIUS (Tunnel-Passwort Attribut) abfragen kann sowie mehrere Passwörter je Gerät (beispielsweise für mehrere Nutzer) unterstützt. Weiterhin ist es auch möglich, den gleichen Satz Passwörer für alle MAC-Adressen zu erlauben - und so die Vorregistrierung der Geräte überflüssig zu machen und doch nutzerspezifische Passwörter zu verwenden. Nicht implementiert - aber prinzipiell möglich - wäre es sogar, weitere Einstellungen (beispw. VLAN) abhängig von der verwendeten Passphrase anzupassen.

Vorteile:

• Keine Fehlkonfiguration am Client möglich - es wird nur die Passphrase für WPA-PSK benötigt.
  
• Automatischer Schutz vor AP-Impersonation und damit ggf. verbundenem Passwortausspionieren, Netzwerküberwachung und Man-In-The-Middle angriffen.
  

Der vielleicht wichtigste Nachteil dabei ist jedoch, dass das Passwort (im Klartext) an jeden der AccessPoints übermittelt werden muss - ein kompromitierter AccessPoint also die WLAN-Zugangsdaten ausspionieren könnte.

Die hostapd-Implementierung für die Übertragung des PSK mittels RADIUS einschließlich der Unterstützung mehrerer PSKs je Gerät ist übrigens im Rahmen des FeM WLAN Projektes entstanden.