Penetration Test Report (KudelskiSecurity-X41): Kudelski X41 Wire Report phase1 20170208

SecurityReview–Phase1
forWireSwissGmbH
FinalReport
2017-02-08
FORPUBLICRELEASE
SecurityReview–Phase1 WireSwissGmbH
Revision Date Change
1 2016-11-24 Startofreview
2 2016-11-28 Initialreportcreation
3 2017-01-04 Finalfindingsadded
4 2017-01-09 DeliverytoWire
5 2017-02-08 Publicversion(formatting,severityratings)
FORPUBLICRELEASE Page1of29
Contents
1 ExecutiveSummary 4
2 Introduction 5
2.1 Findingsoverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 FindingsinProteus(Rust) 7
3.1 WIRE-P1-000:DHacceptsdegeneratekeys. . . . . . . . . . . . . . . . . . . . 7
3.2 WIRE-P1-001:Invalidpublickeysundetected . . . . . . . . . . . . . . . . . . 9
3.3 WIRE-P1-002:Thread-unsafetyrisk . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 WIRE-P1-003:Secretvaluesnotzeroized . . . . . . . . . . . . . . . . . . . . . 14
3.5 Differenceswiththespecifications . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Possibleimprovements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 FindingsinProteus(CoffeeScript) 18
2
SecurityReview–Phase1 WireSwissGmbH
4.1 WIRE-P1-004:DHacceptsdegeneratekeys. . . . . . . . . . . . . . . . . . . . 18
4.2 WIRE-P1-005:Invalidpublickeysundetected . . . . . . . . . . . . . . . . . . 19
4.3 WIRE-P1-006:Secretvaluesnotzeroized . . . . . . . . . . . . . . . . . . . . . 20
4.4 WIRE-P1-007:Thread-unsafetyrisk . . . . . . . . . . . . . . . . . . . . . . . . 21
5 FindingsinCryptoboxandCBOR 22
5.1 WIRE-P1-008:StringsNULLtermination . . . . . . . . . . . . . . . . . . . . . 23
5.2 WIRE-P1-009:Nullpointerscheck . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 WIRE-P1-010:Prekeylengthvalue . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4 WIRE-P1-011:Cryptobox-ctestsbufferoverread . . . . . . . . . . . . . . . . 24
5.5 WIRE-P1-012:CBORarithmeticoverflow . . . . . . . . . . . . . . . . . . . . . 25
5.6 WIRE-P1-013:CBORLaxparsingofserializeddata . . . . . . . . . . . . . . . 27
6 About 29
FORPUBLICRELEASE Page3of29
1 Executive Summary
ThissecurityassessmentfocusedonWire’scorecryptographiccomponents:theProteus
protocol,andtheCryptoboxAPIbuiltoverProteus.
Thecomponentsreviewedwerefoundtohaveahighsecurity,thankstostate-of-the-art
cryptographicprotocolsandalgorithms,andsoftwareengineeringpracticesmitigating
theriskofsoftwarebugs.Issueswerenonethelessfound,withsomeofthempotentially
leading to a degraded security level. None of the issues found is critical in terms of
security.
Weforexamplefoundthatinvalidpublickeyscouldbetransmittedandprocessedwithout
raising an error. As a consequence, the shared secret negotiated by communicating
partiesbecomespredictable, whichinturnsweakenssecurityguaranteesintermsof
“break-in recovery”. The root cause of this issue is a bug in a third-party component
(neglecttoverifyanerrorcode).
Werecommendthatthisissuebefixed,andthatothersecurityimprovementsbeimple-
mentedtoaddressthread-unsafetyrisks,sensitivedatainmemory,andotheraspectsas
describedinthisreport.
The work was performed between November 23rd, 2016 and January 9th, 2017, by
Jean-Philippe Aumasson (Kudelski Security) and Markus Vervier (X41 D-Sec GmbH).
Atotalof14person-dayswerespent,withmostofthetimespentreviewingcodeand
investigatingpotentialsecurityissues.Wireprovidedthesourcecodeofallcomponents
tobereviewed,includingapproximately3300linesorRust,2400linesofCoffeeScript,
and400linesofC.
4
2 Introduction
2.1 F
INDINGS OVERVIEW
DESCRIPTION ID SEVERITY SECTION
InsecureDHratchetkeys(Rust) WIRE-P1-000 LOW 3.1
Invalidpublickeysundetected WIRE-P1-001 LOW 3.2
Thread-unsafetyrisk WIRE-P1-002 MEDIUM 3.3
Secretvaluesnotzeroized WIRE-P1-003 LOW 3.4
InsecureDHratchetkeys(JS) WIRE-P1-004 LOW 4.1
Invalidpublickeysundetected WIRE-P1-005 LOW 4.2
Secretvaluesnotzeroized WIRE-P1-006 LOW 4.3
Thread-unsafetyrisk WIRE-P1-007 MEDIUM 4.4
StringsNULLtermination WIRE-P1-008 MEDIUM 5.1
Nullpointerscheck WIRE-P1-009 LOW 5.2
Prekeylengthvalue WIRE-P1-010 LOW 5.3
Cryptobox-ctestsbufferoverread WIRE-P1-011 MEDIUM 5.4
CBORarithmeticoverflowindecoding WIRE-P1-012 LOW 5.5
CBORLaxparsingofserializeddata WIRE-P1-013 MEDIUM 5.6
Table2.1:Securityrelevantfindings.
2.2 S
COPE
WereviewedtheProteusmessagingprotocolasimplementedintheproteusrepository,
as of November 28th in version 6b317191 (we consider projects as hosted on https:
//github.com/wireapp).Weperformedamostlymanualreviewofthatcode,aswellas
ofitsdependenciescreatedbyWire(cbor-codecandhkdf).
5
SecurityReview–Phase1 WireSwissGmbH
CorecryptographiccomponentswereprovidedbytheSodiumlibraryviawrappersat
https://github.com/dnaq/sodiumoxide.Wedidnotperformacomprehensivereview
ofSodium,butonlyofcertaincomponentscriticaltoProteus’security.
Third-partyreferencesusedforthereviewincludehttps://whispersystems.org/docs/
(Revision1versions),aswellasthereportofapreviousaudit,asprovidedbyWire.
WealsoreviewedtheCryptoboxAPI(cryptoboxrepository)aswellasitsCwrapper
(cryptobox-c).Cryptoboxdefinesasimple,high-levelAPItoProteusinordertohidethe
protocol’scomplexitytocallersinWireapplications.
Finally,wereviewedtheCoffeeScriptcounterpartsofProteusandcryptobox,asimple-
mentedintheproteus.jsandcryptobox.js.
2.3 M
ETHODOLOGY
We sought security issues in the Proteus protocol implementations both in terms of
functionality(doesinbehaveasintended,andinparticularasspecified?),ofsoftware
security(aretheresoftwarebugsexploitablebyanattacker?),andofusage(willtheWire
applicationsuseProteussecurelyviathecryptoboxAPI?).
AlldiscoveredissueswereclassifiedusingCommonWeaknessEnumeration(CWE)1.Due
tothenatureofreviewinglibrarycomponentsandprotocolstheusageoftheCommon
VulnerabilityScoringSystem(CVSS)2wasnotapplicable.Thereforeallissueswererated
usingaseverityratingoflow,medium,highorcriticalbasedonthepossiblesecurityimpact
incommonusecasesandsecurecodinganddesignbestpractices.
1
https://cwe.mitre.org
2
https://www.first.org/cvss
FORPUBLICRELEASE Page6of29
3 Findings in Proteus (Rust)
AsdiscussedwithWire,thefollowingissuesarealreadyknownandtheassociatedriskis
accepted:
• Theversionbyteinamessageenvelopeisnotauthenticated.Thisdoesnoharmin
thecurrentversion,sincetheversionbyteisnotinterpretedbythereceiver.
• Prekeysarenotsigned,whichleavestheprotocolvulnerabletoattackersthat1)
serveforgedprekeysand2)latercompromisetheidentitykeybelongingtothe
supposedcreatoroftheprekeys.
Inthefollowing,wepresentsecurityissuesdiscoveredduringthereview.Weconclude
bydiscussingminordifferenceswiththedocumentedprotocols,andbyproposingim-
provementstotheprotocolandcode.Well-knowninherentpropertiesoftheprotocol
suchasunknownkey-shareattackswillnotbediscussed.
3.1 WIRE-P1-000: DH
ACCEPTS DEGENERATE KEYS
Severity: LOW
CWE: 358
Ifanall-zeroratchetpublickeyisreceived,thentheresultingsharedsecretwillbezero
regardless of the value of the secret key—whereas such a degenerate key should be
rejected as invalid. Therefore, if Bob sends all-zero ratchet public keys, subsequent
7
SecurityReview–Phase1 WireSwissGmbH
messagekeyswillonlydependontherootkeyandnotonAlice’sephemeralprivatekeys.
Adishonestpeermaythereforekeepsendingdegeneratekeysinordertoreducebreak-in
recoveryguarantees,orforceallsessionsinitiatedbyathirdpartytouseasamemessage
key,whileanetworkattackermayforcethefirstmessagekeystoapublicconstantvalue,
forexample.
Therootcauseisthatsodiumoxide’sRustbindingstolibsodiumdonotcheckthereturn
valueofcrypto_scalarmult_curve25519,whereasthecorrespondingCfunctiondoes
checkwhetheritcomputesanall-zerosharedsecret(indicatingadegenerate,insecure
behavior)andreturnsanon-zerovalueinthiscase.
In the proof-of-concept program below, a shared secret is computed using a random
privatekeyskandanallzeropublickeypk:
extern crate sodiumoxide;
fn main() {
sodiumoxide::init();
let pk = [0u8; 32];
let mut sk = [0u8; 32];
sodiumoxide::randombytes::randombytes_into(&mut sk);
let p