1

EFF “Secure” IM Scorecard Review

2

Hello.

3

We’re going to be talking about Privacy vs Security.

4

We’re also going to talk about challenges in securing IM communication.

5

Agenda

• Epilog• Review Part 1 – RetroShare• Review Part 2a – libotr• Threat landscape • Hardening approaches• Prolog

6

Epilog

7

Privacy and encryption has been a regular mainstream topic

8

It’s common for security and privacy to be talked about in the same breath

9

It’s common for security and privacy to be talked about in the same breath

Security is a foundation to building privacy “features”

10

Introducing…

EFF “Secure” “IM” “Scorecard”

“Which apps and tools actually keep your messages safe”.

11

“Actually”?!

12

13

EFF “Secure” IM Scorecard Summary

• A webpage on the EFF site guiding users on the security of IM clients

• It drastically simplifies the problem domain into several “features”:

14

The scorecard logic is a bit perplexing to us...

15

We decided to set aside time to investigate…

• Spend casual hours through 2016 reviewing a selection of clients

• Dedicate up to 24 hours to each client and document the process

• Research the development lifecycle, patching, bug tracking, etc.• Responsibly disclose any vulnerabilities uncovered during the

audits

16

Review Part 1 - RetroShare

17

Retroshare

• Started in 2006• Transport via TLS (OpenSSL)• Auth via PGP keys• Features include:

• Chat / chat channels• Voice and video• Mail• File sharing• Forums• Support Tor / I2P

18

Code Repo

19

First impressions

• Trivial web-based vulnerabilities (e.g. XSS) via the UI• Large attack surface:

• HTTP protocol handling• Rich UI• Low-level serialised protocols• File handling• Multiple 3rd party libraries

• General code quality below par:• Inconsistent retval checking• Signed-ness inconsistencies• Relaxed edge-case handling• Poor usage of typecasting

20

21

22

23

Static analysis results

24

Static analysis results

25

• Vanilla integer overflows to heap corruption in VOIP:

26

• Vanilla integer overflows to OOBR in base serialisation library:

27

28

Developer response

• Communication was easy to establish with PGP keys• Overnight response – very positive and friendly• Issues patched promptly, updated binaries shortly following

11th Jan 2016

Disclosure and

response

13th Jan 2016Patch

developed

9th Feb 2016

Binaries published

29

Developer response

30

Review Part 2 – libotr

31

Libotr

• Is a library, not a client.• Many popular clients for IM protocols leverage it as a plugin to

provide privacy based communication.• Pidgin• Irssi• Miranda• Jitsi• Etc

32

Code repo

33

Initial Impressions• Relatively small code repository• Inconsistency with defensive programming patterns

• A lot of repetition / lack of centralised routines• A lot of “potentially” unsafe integer arithmetic• Not testing return values of memory allocators etc

It was clear to see “knee jerk” patching, where validation is done in response to security advisories.Some crushing of hopes..

34

35

36

37

<- check

38

Developer Responses• We sent one e-mail overnight and had a response waiting in the

inbox by the next morning.• The bug trucker shows a keen interest in resolving issues.• The developers seem to understand secure coding and pay

attention to bug reports that might have an impact.• So far so good.

39

Threat landscape

40

Things may not reach NSA proof…

41

Things may not reach NSA proof… However attacker cost needs to be as high as possible

42

Privacy applications also have different security requirements Compromising the confidentiality of “secrets” == RCE

43

Application functionality

• These clients often have fairly extensive functionality, which each have their own potential attack scenarios, including:• Web and XML-style bugs in UI and rendering = RCE or

deanonymisation• Memory corruption = RCE • Memory leaks = critical information disclosure, RCE reliability• File handle issues = potential information disclosure / RCE• And the list goes on…

44

Further, these clients also pass heavy-lifting to libraries PGP, SSL, Onion Routing, UI, Compression, Images/Video/Audio…

45

Scenario breakdown

• Low investment Common application-level vulnerability classes (web to low level)

• Moderate investment More intricate application-level vulnerabilities Logic level and design issues with adverse security impact Common 3rd party dependency vulnerabilities Passive end-point classification and intrusive targeting

• High investment Overarching low-level protocol vulnerabilities (both passive/intrusive)

46

Hardening improvements

47

Bug bounties (pentesting v2.0)

• Bug bounties can certainly serve a purpose, but its fit and limitations need to be well understood (or else it resembles the next slide)

• If at a certain proven maturity level, then high value bounties can entice skilled researchers to invest time to identify moderate-high resource attack scenarios and findings

• Can be excellent for quickly identifying low hanging fruit and uncovering a range of vulnerability classes, but:• It should not be viewed as a level of assurance or maturity for the

project• Introduces a risk for bandaid / kneejerk patching for specific

vulnerability constructs, without getting to the systemic or implementation pattern flaw

• Create a false sense of security by eradicating simpler bugs while higher skilled threat actors sit on moderate-high skill strategic attacks

48

General best practices

• Clear documentation of architecture, protocols, possible configuration options, and edge cases.

• Security focused “unit” test cases• Hardened binaries adopting latest best practice exploit

mitigation approaches• Sandboxing and hardened platform policies would be ideal, e.g.

grsec policies for containing the running binary – access to the underlying file-system and syscalls

• Good issue tracker, easy to find security contact with PGP keys available

49

Fuzzing

- Very useful in bashing out bugs of all kinds without much human effort

- Needs initial time investment to get fuzzer implemented- Needs some time investment to follow up on its results

- It’s important that if fuzzing is used that it’s done correctly – otherwise lack of results might lead to a false sense of security.- For example, encryption heavy code is likely to fail early on each

mutation. Your fuzzer should hopefully take this into consideration then and do what’s needed to get better code coverage.

- It’s unlikely to find more complicated issues, so shouldn’t be relied upon as the only security testing for a project.

50

Static analysis

• There is a number of potential compile time static analysis techniques, both open-source (e.g. clang) to commercial (e.g. Coverity)

• Static analysis tooling can introduce both false negatives and false positives (the latter being time heavy to investigate)

• Can be beneficial identifying LHF but also identify bad constructs in code – encourages overall cleanliness and developers to follow best practices

• Can provide useful metrics and tracking of security issues and improvements over time

51

Code audits

• The quality of a code audit depends on who you have on it, and the auditors understanding and experience of the relevant technology stack – this influences the effectiveness drastically (e.g. the read() example)

• Code audits should not be a simple snapshot of “findings”, but provide ongoing guidance to the developers for the overall architecture and coding practices of the application

• We believe dedicated audits from experienced folk should only really occur after applications meet a certain bar

52

Prolog

53

Key takeaways

• Neither products so far meet the bar required for “keeping you safe”, factoring in the complicated threat scenarios for privacy software

• Judging software security on publicised vulnerabilities is misleading

• The scorecard needs improvements and ongoing maintenance otherwise it may introduce risk to users

General rule of thumb:• simple foundations + minimal functionality = promising

54

Next steps

• We’re in disclosure with libotr now and will do part 2b at Wahckon

• A part 2 blog post will be coming out in May • We will review 1 or 2 clients not in the scorecard, including

Richochet• We will review 1 or 2 other popular clients in the scorecard soon• Potentially, we will look at common libraries used by many

clients

55

Thanks for listening!

Questions?