Addressing FreeRDP security issues in Debian jessie (and stretch)

[Mike Gabriel <mike.gabriel@das-netzwerkteam.de>]

Hi,

I'd like to discuss the possible pathways for getting FreeRDP fixed in  
Debian jessie LTS (and Debian stretch, too).

Last week I talked to Bernhard Miklautz (one of the FreeRDP upsteam  
maintainers and the actual packager of FreeRDPv2 in Debian).

1. Looking at fixing FreeRDP v1.1 in jessie / stretch
-----------------------------------------------------

He sketched up the following pathway for getting freerdp (v1.1) fixed  
in Debian jessie (and stretch):

  * Backport https://github.com/FreeRDP/FreeRDP/pull/4499
    -> required for FreeRDP in jessie/stretch to be able to connect  
to current RDP servers
       (not a security issue, but a functionality issue due to  
Microsoft updates rolled out
       during Q1 / 2018).
    -> estimated effort: 1-2h

  * CVE-2018-8785: not needed for jessie / stretch (code not present)

  * CVE-2018-8786,
    CVE-2018-8789: estimated hours for all three: 1-2h

  * CVE-2018-8787: estimated hours: 1-2h
  * CVE-2018-8788: can be become quite an effort, estimated time: 2h++

  * CVE-2018-8784: not needed for jessie / stretch (code not present)


While this sounds nice and feasible the underlying tone of investing  
so much work into FreeRDP v1.1 was a different one.

E.g. the fix for CVE-2018-8789 should be quick and simple. But the  
surrounding code is buggy to a great extent, too.

There have been so many stabilizing code fixes over the past 1-2 years.


2. Backporting FreeRDP v2 from buster to jessie and stretch
------------------------------------------------------------

Another approach, with a more stable and usable result is backporting  
FreeRDP v2 to jessie and stretch right away.

Most people (I hope) are using freerdp2-x11 from stretch-backports  
(plus remmina from stretch-bpo) on Debian stable these days (freerdp  
1.1 in stretch is broken with Windows RDP servers that are up-to-date  
with their patch levels).

libfreerdp-client1.1
  Reverse Depends: freerdp-x11 (>= 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1)
  Reverse Depends: libfreerdp-dbg (=  
1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1)
  Reverse Depends: libfreerdp-dev (=  
1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1)
  Reverse Depends: libguac-client-rdp0 (>= 0.8.3-1+b2)
  Reverse Depends: libxfreerdp-client1.1 (>=  
1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1)
  Reverse Depends: remmina-plugin-rdp (>= 1.1.1-2)
  Reverse Depends: vlc (>= 2.2.7-1~deb8u1)
freerdp-x11
  Reverse Depends: freerdp-x11-dbg (=  
1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1)
  Reverse Depends: ltsp-client (5.5.4-4)

So the plan could be this:

  - rebuild freerdp (v1.1) as a shared libs package only, drop  
freerdp-x11 (which
    contains the command line tool)

  - backport freerdp2 from Debian unstable to jessie/stretch
  - backport remmina from Debian unstable to jessie/stretch
  - rebuild vlc in jessie (and possibly stretch, too) without RDP support
  - ltsp-client: adapt command line syntax to new FreeRDP2 cli style

  - libguac-client-rdp0: leave as is... Guacamole upstream still believes in
    FreeRDP v1.1 shared lib API...

Summary
-------

Before going any deeper into this, I'd love to get some feedback from  
the LTS and the security team about the proposed strategies. Are there  
other possible pathways to go? If so, please share yours.

The FreeRDP v1.1 backporting work (8-10 hours) would have to be  
outsourced to ThinCast in Austria (where most FreeRDP upstream devs  
work these days).

Looking forward to your ideas and comments,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

Attachment: pgpiQReN6HdqB.pgp
Description: Digitale PGP-Signatur