Security improvements in {\TeX} Live Study of Mathematical Software and Its Effective Use for Mathematics Education

Security improvements

in

_Iff

Live

PREINING Norbert

アクセリア株式会社、東京都

Tr

Live Team

北陸先端科学技術大学院大学、能美市

Abstract

Wereport onsecurity improvements inthe

TEX

Live distribution introduced

for the release 2016. We present

possible

attack vectors on older releases, and

explainhow therecent _changesrender these attackvectors_impossible.

1

Introduction

Since the switch to the current distribution method and the introduction of network installs and

_updates,

many

things

have

changed

inthe

TEX

(Live)

world. Butone

thing

hasn’t

_kept

_up with thenewdistribution methods:

security.

Therewas

hardly

_any verification

going

onwhether the

package

downloaded from

theCTANmirrorshaven’t been

_tampered

with. And

_although

we are

shipping

checksum

and file size

_information,

thesewere

only

usedon rareinstances

(when

restarting

afailed

installation).

We will recall the

_{general layout}

of the

_{i\mathrm{E}\mathfrak{c}}

Live

_{distribution,}

aswell asthe

security

state up till release 2015 and

_possible

attack vectors onto

_TEX

Live installations in Section 1.1. The

_following

Section 2

_explains

the new

security

infrastructure and how

integrity

and

_authenticity

canbe

guaranteed by

it. The

following

Section 3 is dedicated

to

_{implementational}

and social

_problems

we faced in the _process of

introducing

these

changes,

aswell as

general

user

experience.

1.1

Overview

on

the

TEX

Live distribution model

While we cannot

_give

a detailed

explanation

of the

internals,

as well as refrain from

giving

a

practical

introduction to

using

the

\mathrm{J}\mathrm{B}K

Live

Manager tlmgr,

wewant to

give

anoverviewhow

packages

areinstalled

by

_tlmgr

(and

similarly

by

the install

script),

as

this is a _necessary

prerequisite

in

understanding

the

security

implications.

We assume

that the reader has

experience

in

_using

_{[\mathrm{p}\mathfrak{c}}

Live as well as the \mathrm{T} Live

Manager

tlmgr.

Every Iffl

Live

_instance,

that is_anyactual installationon auser’s

_computer,

aswell

asthe

repositories

used to distribute

_{TEX Live,}

carries all of the relevant information bundledinone

file,

theso call?

$\Psi$

Live Database

[4],

normally

named texlive.

tlpdb.

Thisfile contains

_general

information about the

_instance,

like

_setting

of the usedrepos‐

itories,

or distribution

format,

as well as all contained

packages

with list of files etc.

Thus,

this file

_plays

acentralrole in_every

operation tlmgr

is

carrying

out.

In

_particular,

what

_happens

whena userasks

_tlmgr

to

update

the installationisthe

1.

_tlmgr

loads the local database and determines the set of installed

_packages,

2. loads theremotedatabase

_(the

onefrom the used

repository)

3. compares the revision numbers and determines

packages

that need to be up‐

date/added/removed,

4. for each

_package

tobe

_updated

_(or

_installed)

between 1 and 3socalled containers

(currently

tar.xz

arhcives)

are

downloaded,

5. each container is

_unpacked

into the destination tree and the local database up‐ dated.

1.2

_IEX

Live

_security

_{status up to}

release

2015

Till

_2015,

thetexlive._tlpdbattheserversdidcontaincertain

consistency information,

in

_particular

the sizeof the containersaswellastheir checksum

(md5),

seethe

following

excerpt

from atexlive.

_tlpdb:

name _{12 many}

containersize 2100

\mathrm{c}ontainermd5 . . . . .

doccontainersize 375404

do\mathrm{c}containermd5 . . . .

This information could be used to at least

_guarantee

that the correct containers have been

_downloaded,

but it turned out that our _programs, in

particular

_tlmgr

and

the installation routines did not use these information

during

normal _runs, but

only

during interrupted

installations. 1.3

Possible

attack

vectors

Improving

security

brings

firsta

complication

of the_necessary

software,

increasedwork‐

load of the

_maintainers,

changed

behaviorforusers, and thus it is wise to discuss first whether a better

security

model is _necessary. This can be done

by

scrutinizing

the

infrastructure for

_possible

attack_vectors,and

_looking

attheconsequencesfor theusers.

Weconsider theworstcasescenario for the_user,

namely

thata

crypto‐virus

infected

the_computer and all data is lost.

1.3.1 Attackvector 1

In the

_simplest

case an attackcanbe carried out

_by

the

_following

_steps: 1.

_compromise

oneCTAN mirror

2.

_exchange

the

_{pdftex binary}

with one

shipping

a

crypto‐virus

3. wait forusersto

update

Itmustbenoted that worldwide thereare alot of differentCTAN

_mirrors,

_practically

all of themoutofour

personal

control. Wecannoteven check the

security

levelonthese

This attackvector could be blocked

_by

_{actually checking}

the checksum as

provided

by

the texlive.

_tlpdb.

And while

changes implementing

this feature have been in tlcritical

_(a

_{testing repository}

for

_changes

totheinfra‐structure of

_{\mathrm{I}|\mathrm{E}\mathrm{X}}

_Live),

these

changes

werenever

shipped

out tousers.

1.3.2 Attackvector 2

Another

_possible

attach_vector, a bit more involved than the

previous,

consists of the

above

_steps

_plus

one more:

1.

_compromise

one CTANmirror

2.

_exchange

the

_{pdftex binary}

with one

shipping

a

crypto‐virus

3.

_adjust

the containerin a_waythat the checksum doesnot

change

4. waitforusersto

update

Here the attacker would

_byte‐pad

the container in a _waythat the checksum isnot

changed.

Notethat while thisis

_possible

for the checksum

_algorithm

wehave been

using

till now

(MD5),

the

requirement

that the

resulting

file still works as a tar.xz archive

restricts this attack.

While less

_likely

to

_happen,

this attackvectorcouldn’t be blocked_uptill release 2016.

1.4

Attack

vector 3

Finally,

let us consider themost

probable

attackvector:

1.

_compromise

one CTANmirror

_(or

set one_up

yourself!)

2.

_exchange

the

_{pdftex binary}

with one

shipping

a

crypto‐virus

3.

_adjust

the checksuminthe texlive.

_tlpdb

4. waitforusersto

_update

Indeed,

an intruder that can

change

the containers itselfis ofcourse also able to

change

the data in the texlive.

_tlpdb,

thus

_rendering

all

_protective

measures futile.

Again,

uptill release 2016 therewas no_{way to} handle this attackvector.

This short list of rather

_simple

attack scenarios

_gives

a clear indication that there is

ample

way to

improve.

2

_Security

infrastructure

From the

_previous

discussion on

possible

attack vectors one can extract two

require‐

ments of the distribution mechanism necessary to

guarantee security:

Integrity

and

authenticity

Integrity

of the

_packages

downloaded: Here anykind of

tampering

should be

caught,

not

_{only by}

intruders but also

_by

errorsinthe download_processor diskerrors on

theserver.

Checksums are

normally

used for

integrity,

and because the

currently

used MD5

isnot

_strong

_enough,

we have switchedto SHA512.

Authenticity

guarantees

thatthe

_package

downloaded is

_actually

theonethatwethe

To

_guarantee

_authenticity

weintroduced

cryptographic signatures.

2.1

Overview of the

verification architecture

The

_general

flow of

_package

download and verification isasfollows:

Checking

authenticity

of the downloaded texlive.

_tlpdb

is done

_by

first down‐

loading

its

_respective

checksum texlive._{tlpdb. sha512,} as well as the

cryptographic

signature

of the checksum

_file,

namedtexlive.

_tlpdb.

sha512.asc. TheGNU

Privacy

Guard

_(gnupg)

is used to

_verify

that the downloaded

_signature

and the checksumfile agree. We refer the reader to introductions to

asymmetric

cryptography

concerning

details of this _process.

texlive.

_tlpdb

\rightarrow texlive.

tlpdb.

sha512

name 00texlive.

_config

<128\mathrm{h}・ \mathrm{x}

_digits

>\mathrm{t}・ \mathrm{x}・ \mathrm{i}・\mathrm{e}.\mathrm{t}

_・・

\mathrm{d}\mathrm{b}

\downarrow

texlive.

_tlpdb.

sha512.asc

name 12many

containerchecksum ...

----‐BEGIN PGP

SIGNATURE

iQEVAwUBVyAV9kzhh3.

..

name

_{2\mathrm{u}\mathrm{p}}

\mathrm{r}2\mathrm{m}\mathrm{B}9\mathrm{x}\mathrm{E}\mathrm{n}\mathrm{R}402 SRBDNI\ldots

containerchecksum ... .. .

----‐END PGP SIGNATURE

2.2

The

_{signing key}

Asymmetric

cryptography

involves a

key‐pair

with a

_private

and a

pubhc

key.

The

private

key

is usedto create

_signatures,

and the

_public

_key

isused to

_verify

_signatures

(encryption

is anotheruse _case, butnot relevantto this

article).

The

private

key

used

is

_(slighly

edited_output to fit the

_page):

pub 2048\mathrm{R}/06\mathrm{B}\mathrm{A}\mathrm{B}6\mathrm{B}\mathrm{C} 2016−03−19

Key fingerprint=\mathrm{C}78\mathrm{B} 82\mathrm{D}8 C795 12\mathrm{F}7 9\mathrm{C}\mathrm{C}0 \mathrm{D}7\mathrm{C}8 0\mathrm{D}5\mathrm{E} 5\mathrm{D}91 06\mathrm{B}\mathrm{A} \mathrm{B}6\mathrm{B}\mathrm{C} uid TeX Live Distribution <\mathrm{t}\mathrm{e}\mathrm{x}_{‐live@tug.org}>

sig 3 06\mathrm{B}\mathrm{A}\mathrm{B}6\mathrm{B}\mathrm{C} 2016-03-19 TeX Live Distribution <\mathrm{t}\mathrm{e}\mathrm{x}_{‐live@tug.org}>

sig 3 06\mathrm{B}\mathrm{A}\mathrm{B}6\mathrm{B}\mathrm{C} 2016-03-19 TeX Live Distribution <\mathrm{t}\mathrm{e}\mathrm{x}_{‐live@tug.org}>

sig 860\mathrm{C}\mathrm{D}\mathrm{C}13 2016-03-20 Norbert _Preining <_{norbert@preining.}info>

It

_carries,

besidesthe

_{self‐signatures,}

the

_signatures

of Karl

_Berry

and

_myself,

and thus allows_{easy trust}verificationsincebothour

keys

areavailable from the usual

key

_servers, aswell asin mycasethe Debian

keyring.

As atechnical

detail,

we arenot

_using

the actual

_{private key}

to

_generate

_signatures,

buta socalled

sub‐key,

and

keep

the main

key

completely

off‐line. This

guarantees

that

in caseofa breachof the_tug.orgserver and

compromise

of the used

signing key,

the

main

_key

is not

_compromised

aindcanbe usedtorevoke the

_subkey

and

_generate

a new

one.

2.3

Discussion

2.3.1

_Integrity

Due to the

_stringent

verification of checksums of all downloaded

_files,

the

_integrity

of

any

packages

is

guaranteed.

2.3.2

_Authenticity

ofthe containers

Authenticity

of the downloaded

_{$\tau$ \mathrm{f}X}

Live Database texlive.

_tlpdb

is

_{given by}

the

cryptographic signature.

Authenticity

of the downloaded containers is

_guaranteed

_by

the fact that the checksum information for each containers is taken from the

_(authen‐

ticated)

database,

and the checksum

_algorithm

_(SHA512)

cannot

_(at

thecurrent

_time)

be

_tampered

with.

3

Practical

_problems

and

user

experience

As

_expected,

wedid facea

long

list of

problems

and

surprises

during

the

implementation,

testing,

and transition course. In this last

_part

we discuss a few of

them,

and howwe

worked around

_it,

and also

_report

onthe user

_experience.

3.1

_{(Non‐)Distribution}

of GnuPG

The whole

_setup

isbased on the fact that the GNU

Privacy

Guard GnuPG

[2]

is avail‐

able. Without

_it,

_authenticity

cannotbe

_guaranteed,

and as_consequencealso

integrity.

Practically

all Unix‐like distributions

_{ship GnuPG,}

but there are twonotable and im‐

portant

exceptions:

Windows and OSX. The default solution—as we do it for other

programs

commonly

availableon most

platforms

but Windows and

Mac,

_{e.g., wget‐}

would be to

ship

binaries of GnuPG with

_{r\mathrm{E}\mathfrak{c}}

Live.

Unfortunately,

duetoa

long history

of

ignorant

legislative bodies, import

andexport

of

_crytographic

software is

_(might

still

_be)

_heavily

restricted insome

countries,

governed

by

theWaasenaar

_Arrangement

_{[1]. (For}

those who remember how the first_copyof PGP reached

_{Europe, they}

will understand

_easily!)

And

_although

the situation has

_changed

slightly

and export seems to be less restricted

nowadays,

import

into some

countries,

notably

France and

_India,

seemstobe a_no‐go.

As TUGwedo not want to

_get

involved into

_legal

_problems

when

_sending

DVDs into

3.2

Alternative distribution of GnuPG

To

_mitigate

the

_problems

described in the

_{previous section,}

I

_personally

did _{set up} a

repository containing

GnuPG binaries for Windows and

Mac,

which allows users to

simply

add GnuPG after the initial installation. To obtain GnuPG for either of the

mentioned

_{platforms, simply}

issuethe

_following

command

tlmgr

−repo

http:

//\mathrm{w}\mathrm{w}\mathrm{w}.preining.

\displaystyle \inf 0/\mathrm{t}\mathrm{l}\mathrm{g}\mathrm{p}\mathrm{g}/

install

tlgpg

On the

Mac,

the

_{\mathrm{E}\mathfrak{c}}

Live

_Utility

_(TLU)

_already

offers to install GnuPG from this location on first _run, and the

$\Psi$ \mathrm{X}

Live infrastructure itself is

prepared

to use the

GnuPG installed via this_way.

3.3

_Computing

checksums

Another

_problem

wefacedishowto

compute checksums,

in

particular

SHA512. There is an excellentand

quick

Perl module

_Digest:

:SHAwhichwe

initially used,

but it turned

outthe the default Perl distributioneven on newMacs

is,

well, old,

_very

old,

and does

not

_ship

this module.

We tried a view different

options,

like pure Perl

implementations,

or Lua

imple‐

mentations,

but all of them werefar to slow for the amount of checksums we have to

computer.

Asasolutionwe

implemented

amulti‐trial

system:

Firstthe existenceof

Digest:

:SHA is checked. If it is not

_available,

the

_following

command line programs are checked in

order:

_openssl,

\mathrm{s}\mathrm{h}\mathrm{a}512\mathrm{s}\mathrm{u}\mathrm{m}, and shasum. One or the other should be available on all

platforms.

3.4

Users‘

_complains

and

_experience

As laid out in the

_{introduction,}

one of the aims was that the user

experience

should

change

aslittleas

possible.

During

theinitial

testing phase

we

got quite

some

complains

that our initial

implementation

and _wayof

warning

users was to

_intrusive,

too

_rough.

We have reworked the user

experience

ina _way

that, although

things

are checked and

verified as far as

possible, only

in worst‐case scenarios the user is

warned,

the rest of the

_changes

areminimal.

In

_particular,

for the

_tlmgr

calls we nowhave the

following layout:

tlmgr

update

-‐list

-‐repo <CTAN>/\mathrm{t}\mathrm{l}\mathrm{n}\mathrm{e}\mathrm{t}/

tlmgr:

package repository

<CTAN>/\mathrm{t}\mathrm{l}\mathrm{n}\mathrm{e}\mathrm{t}/ (verified) The

_only

new

part

is the (verified)

part,

which also

might

look like

(not verified: <reason>

wherethereasons areeithera

missing GnuPG,

or a

missing signature

ontheserverside.

Only

in case that a

signature

was checked and couldn’t be

verified,

the user will

3.5

_{Key management}

Immediately

after releasewereceived_requestfor

supporting

different

signature

keys

for

alternative

_{repositories.}

I thus have added

_key

_{management functions, tlmgr key,}

that allows for

_listing,

_adding,

and

_removing

of additional

_keys

tothe trusted list of

_signing

keys.

This feature is

_already

inuse

by

atleast the

KOMA‐Script

project

[3].

4

Conclusion

With the release 2016 of

_TEX

Live we are now _{up to} the same standard of

major

Linux distributions which ensure

authenticity

via

cryptographic

signatures.

Although

inthe

_long

years of

$\pi$ \mathrm{x}

Live

being

out

_there,

notone case of abuse has been

reported,

we believe thatin the current environment with

high

risk viruses

being

distributed in

ever

evolving

schemes,

to

_support

verification of

authenticity

and

integrity

is a

_great

step forward. A step that most users will not even realize it has been

made,

but still

important.

References

[1]

The Wassenaar

_Arrangement

on

Export

Controls for Conventional Arms and

Dual‐Use Goods and

_{Technologies.}

_https:

//\mathrm{e}\mathrm{n}.

wikipedia.

\mathrm{o}\mathrm{r}\mathrm{g}/\mathrm{w}\mathrm{i}\mathrm{k}\mathrm{i}/\mathrm{W}\mathrm{a}\mathrm{s}\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{a}\mathrm{r}_{-}

Arrangement.

[2]

Werner Kochet al. GNU

_Privacy

Guard GnuPG.

_http:

//\mathrm{w}\mathrm{w}\mathrm{w}.gnupg.

\mathrm{o}\mathrm{r}\mathrm{g}/.

[3]

Markus Kohm.

KOMA‐Script.

htt.

_{\mathrm{p}://\mathrm{w}\mathrm{w}\mathrm{w}}

.

komascript.

\mathrm{d}\mathrm{e}/.

[4]

Norbert

_{Preining. TEX}

Live’s new infrastructure.

ArsTEXnica,

4:69−73,

October