A Meta-level Approach for Multilingual Taint Analysis

Damian M. Lyons

∗

and Dino Becaj

∗

Fordham University, New York, U.S.A.

Keywords:

Multilingual, Static Analysis, Taint Analysis, Software Engineering.

Abstract:

It is increasingly common for software developers to leverage the features and ease-of-use of different lan-

guages in building software systems. Nonetheless, interaction between different languages has proven to be a

source of software engineering concerns. Existing static analysis tools handle the software engineering con-

cerns of monolingual software but there is little general work for multilingual systems despite the increasing

visibility of these systems. While recent work in this area has greatly extended the scope of multilingual static

analysis systems, the focus has still been on a primary, host language interacting with subsidiary, guest lan-

guage functions. In this paper we propose a novel approach that does not privilege any one language and has

a modular way to include new languages. We present an approach to multilingual taint analysis (a security

oriented static analysis method) as a ‘meta-level’ algorithm which includes monolingual static analysis as a

special case. A complexity analysis of the taint analysis algorithm is presented along with a detailed ‘deep’

multilingual example with Python and C/C++ software. A performance analysis is presented on a collection

of 20 public, multilingual repositories selected from github. Our results show an average of 76% improved

coverage using our algorithm when compared to monolingual taint analysis.

1 INTRODUCTION

It is challenging to track the ﬂow of sensitive data

within a software application to determine if the data

is being dangerously exposed (Boxler and Walcott,

2018; Alashjaee et al., 2019). Smartphone apps, in

particular, have the potential to expose sensitive per-

sonal information, so analysis for Android applica-

tions has received early attention (Arzt, 2014). Taint

analysis methods address this challenge by follow-

ing the ﬂow of sensitive (‘tainted’) data in a program

to determine if it is being leaked to a ‘sink’ loca-

tion without being ‘sanitized’. These methods oper-

ate either by static analysis of the program (Boxler

and Walcott, 2018) or by observing dynamic runs of

the program (Alashjaee et al., 2019). This problem is

complicated in multilingual software systems, deﬁned

as systems composed of software written in different

computer languages, because data ﬂows are difﬁcult

to trace across the language boundaries.

Software developers increasingly leverage fea-

tures from different languages to implement required

functionality more quickly and effectively, resulting

in multilingual software systems. The beneﬁt comes

∗

The authors are partially supported by grant DL-

47359-15016 from Bloomberg LP.

at a cost: Mayer et al. (Mayer et al., 2017) reported

that 90% of software developers request help with

multilingual codebases on issues such as unexpected

interactions between languages and security breaches.

One reason for this is that cross-language operations

are typically opaque. While many IDEs and tools ex-

ist to assist a developer in visualizing and analyzing

monolingual code, whole program analysis of a mul-

tilingual code base is not as well supported. This

is especially true for languages such as JavaScript

and Python that typically leverage a rich collection

of libraries written in other languages (Madsen et al.,

2013).

The paper presents a novel approach to the prob-

lem of multilingual taint analysis. Building on our

prior work in analysis of multilingual systems (Lyons

et al., 2018; Lyons et al., 2019; Lyons and Zahra,

2020), it proposes a meta-level multilingual static

taint analysis algorithm that includes monolingual

taint analysis as a special case. There are several ways

in which a program in a host language can invoke a

function in a different, guest language, and we fo-

cus on one of these: the Foreign Function Interface

(FFI). Using an FFI, a host language program can call

a guest language program as a function call. There

may be many different host FFI packages for any two

Lyons, D. and Becaj, D.

A Meta-level Approach for Multilingual Taint Analysis.

DOI: 10.5220/0010543800690077

In Proceedings of the 16th International Conference on Software Technologies (ICSOFT 2021), pages 69-77

ISBN: 978-989-758-523-4

languages (E.g., Python/C++: PyBoost, pybind11,

python.h,. . . ) and more appear regularly. Our pro-

posed solution targets an open-ended aproach to FFI

packages and languages by modularizing the mono-

lingual taint analysis step.

The next section reviews relevant prior literature

and motivates the proposed approach. Section 3 in-

troduces the approach and presents our primary con-

tribution, the Multilingual Taint Analysis (MTA) al-

gorithm. Section 4 describes the architecture and pre-

liminary implementation of the version of MTA used

for performance testing along with a detailed exam-

ple. Section 5 presents the experimental results from

performance testing. Using a sample codebase of

public multilingual repositories, we show that MTA

improves the coverage, or proportion of suspicious

source code opened to inspection, by 76 % on aver-

age. The ﬁnal section summarizes our contributions

and presents conclusions and plans for future work.

2 RELATED WORK

Individual software designers may elect to write some

parts of their software in one language and some in

another but studies indicate that the interaction be-

tween languages is often a cause of software engi-

neering concerns (Mayer et al., 2017). Programs in

different languages can interact by interprocess com-

munication (IPC), by embedding (e.g., SQL in FOR-

TRAN or JavaScript in HTML), or by employing a

host language Foreign Function Interface (FFI), and

each has been studied. This paper falls into the FFI

category (Furr and Foster, 2005; Lyons et al., 2018;

Lee et al., 2020). Since all software ultimately must

translate to the machine language for execution, an-

other approach to multilingual analysis is to leverage

a common runtime (Grimmer et al., 2018). Our ob-

jective is to provide direct feedback as the software

is being developed rather than analysis of (possibly

binary) executables and thus we employ static analy-

sis of source code rather than dynamic analysis or a

common runtime.

Taint analysis can be carried out by dynamic anal-

ysis (Alashjaee et al., 2019) or static analysis (Boxler

and Walcott, 2018) of the program. Dynamic anal-

ysis involves tracing through the program as it exe-

cutes whereas static analysis evaluates the program

without execution. Each approach has advantages

and drawbacks: Dynamic analysis is limited to sam-

ples of execution but accurately reﬂects the execu-

tions of the program, whereas static analysis covers

all possible executions but typically needs to be con-

servative to address issues of soundness and com-

pleteness. Kreindl et al. (Kreindl et al., 2019;

Kreindl et al., 2020) present a multi-lingual dynamic

taint analysis that is based on their GraalVM run-

time. Motivated by the opacity of cross-language

function calls (as are we), they support efﬁcient dy-

namic taint analysis in a selection of dynamic and

low-level languages. The implementation leverages

GraalVM, a multi-language virtual machine. The

architecture employs a language-agnostic core and

multiple, language-speciﬁc front-ends. Our objec-

tive is to develop a static analysis approach to multi-

language taint analysis, however, the general structure

of (Kreindl et al., 2019) into language-agnostic and

langiage-speciﬁc modules is something we feel is ex-

ceptionally valuable.

It is not uncommon for IDEs to support static

analysis in multiple languages (e.g., Eclipse) but it

is uncommon to handle whole programs consisting

of more than one language. HybriDroid (Lee et al.,

2016) can handle mixed Android Java and JavaScript

but the approach is not general. (Lee et al., 2020)

proposes semantic summaries of FFI calls as a more

general framework. (Madsen et al., 2013) use pointer

and use-case analysis to analyze JavaScript calls to

library functions in other languages. However, the fo-

cus in both is on a primary host language handling

subsidiary guest language functions. A multilingual

codebase might contain no primary host language –

there may be major components written in each lan-

guage. Our approach is motivated by this observation

to consider multilingual analysis as a ‘meta-level’ al-

gorithm that incorporates each monlingual analysis as

a component.

3 APPROACH

The meta-level approach proposed here is based on

two observations:

1. Good quality monolingual taint analysis tools ex-

ist and will continue to be developed and im-

proved; and,

2. New FFI packages for multilingual programming

are being developed all the time.

The ﬁrst observation is easily supported.

Many capable taint analysis tools are avail-

able today: Quandary/Infer (fbinfer.com),

Pyre/Pysa (pyre-check.org), FlowDroid (blogs.uni-

paderborn.de/sse/tools/ﬂowdroid), SonarCloud

(soinarcloud.io) and others. To support the second

observation, we need only look at C++/Python FFI

packages. The oldest package is the python.h FFI, the

Python/C API. However, Boost.Python(boost.org)

ICSOFT 2021 - 16th International Conference on Software Technologies

was developed shortly after to offer a more seam-

less way to call C++ from Python. Subsequently,

pybind11 (pybind11.readthedocs.io) was developed

to offer the same functionality but in a header-only

package. In the case of Java, the basic FFI is the Java

Native Interface, JNI. But JNA (github.com/java-

native-access) and JNR are FFI packages that each

offer an interface improved in different ways.

Taking these two fundamental observations into

account, we propose that the best design for a multi-

lingual taint analysis system is one that views mono-

lingual taint analysis and FFI packages as modular

components that can be added or removed as needed.

We start by introducing some terminology.

3.1 Multilingual Taint Analysis

Let P

be the compilation unit in source language `

that is to be analyzed. Let ST (P

) be the set of state-

ments and VA(P

) be the set of variables in P

. For

convenience we will just use ST and VA when clear.

Some s ∈ ST may be function calls to a foreign

function interface (FFI). If (a, s) ∈ FFI

`,`

then s ∈ ST

is a foreign function call from host language ` to a

function in guest language `

with argument a. We

only consider the case in which the source for the for-

eign function call is also available for analysis.

We will assume that for every source language

` ∈ L there is a taint analysis function TA

deﬁned

as follows

,Src,Snk) = L (1)

• P

is a compilation unit in source language `.

• Src = {(v, s) : s ∈ ST, v ∈ VA} where v in statement

s is a source of taint.

• Snk = {(v, s) : s ∈ ST, v ∈ VA} where v in state-

ment s is a sink to be monitored for taint.

• L = {C

: i ∈ {1, . . ., n}} is a set of taint lists C

• C ∈ L is a sequence (c

), c

= (v

), j ∈

{0,. . ., m}, where

– s

j+1

follows s

in a possible execution of P

;

– if v

is tainted in s

then v

j+1

is tainted in s

j+1

;

– (v

) ∈ Src, each taint list begins at a source;

and,

– (v

) ∈ Snk, each taint list ends at a sink.

Using P

and FFI

`,`

as deﬁned, we apply TA

with

the sink set extended to include all the foreign func-

tion calls:

,Src,Snk

[

∈L

FFI

`,`

) = L

(2)

The sanitizer argument is hidden throughout, just for

clarity

Where L

= L − {`}. Some taint lists in L

may now

end with calls to a foreign function, indicating that

taint is being passed to that function through an argu-

ment. We propose a mechanism below to continue the

taint analysis across the multilingual boundary.

Let last(C),C ∈ L

be the ﬁnal member, c

, of

the taint list C. If last(C) ∈ FFI

`,ell

, then to fur-

ther analyze the taint, it is necessary to switch to lan-

guage `

. However, there is no program P

to ana-

lyze with TA

. To address this, an artiﬁcial linkage

program is created from last(C) = (a,s) the foreign

function call statement s with argument tainted argu-

ment a. Lnk

`,`

(a,s) is an artiﬁcial linkage program in

language `

that declares, sets up the arguments, and

then calls the `

foreign function. Analysis of taint

continues in `

, where P

= Lnk

`,`

(a,s):

,Src

,Snk

[

∈L

FFI

) = L

(3)

where

• Src

includes the original argument and call to the

foreign function.

• Snk

includes the return from the function and any

other arguments (to catch side-effects).

Consider Algorithm 1 which has arguments:

• P

• FFI = {FFI

`,`

: `,`

∈ L } - all available foreign

function interfaces,

• Srcs = {Src

: ` ∈ L } - all language speciﬁc taint

sources,

• Snks = {Snk

: ` ∈ L } - all language speciﬁc taint

sinks.

The algorithm must allow for multiple sequential and

nested calls to eq.(3) from eq.(2), supporting mutually

recursive function calls between languages.

MTA recursively constructs a set L of multilingual

taint lists. The repeat loop continually evaluates taint

analysis until no further items can be added to L. The

for loop calls MTA recursively for any foreign func-

tion call found. If the call propagated taint, then it is

added to the list of taint sources and is explored by

on the next iteration of the repeat.

3.2 Termination

Let us consider under what conditions MTA will ter-

minate. It is reasonable to assume that there is a ﬁ-

nite list of foreign function calls across all the source

ﬁles available for analysis. Each traversal of the for

C ∈ L loop will encounter either new foreign function

calls in last(C) or calls already encountered. New

A Meta-level Approach for Multilingual Taint Analysis

Algorithm 1: Multilingual Taint Analysis Algorithm.

function MTA(P

,FFI,Srcs,Snks) returns L

L ←

repeat

L ← L

L ← L ∪ TA

,Src

,Snk

FFI

`,`

)

for C ∈ L such that last(C) ∈ FFI

`,`

← Lnk

`,`

(last(C))

← MTA(P

,FFI,Srcs,Snks)

for C

∈ L

if last(C

) 6∈

FFI

`,`

then

Src

← Src

∪ last(C)

end if

end for

L ← L ∪ L

end for

until L =

return L

end function

calls will expand L by L ∪L

; however, previously en-

countered calls will not, since any taint lists generated

will already be in L. Since the list of foreign function

calls is ﬁnite, and since the for loop makes progress

through this list each time, ultimately there will be

no more new calls encountered. After this happens,

L will not increase in size and the repeat loop will

terminate.

3.3 Complexity

A convenient measure of computational complexity is

how often a monolingual taint analysis is conducted

. For worst case analysis, we will assume that

taint is found to reach the foreign function call, prop-

agate through it, and reach a sink beyond it. Let n be

the total number of foreign function calls and let d be

the maximum nesting of calls.

Consider a simple case n = 1, d = 1: a program

that makes one foreign function call that in turn calls

no other foreign functions. The repeat loop makes

one TA call and the subsequent for loop makes a re-

cursive MTA call to determine whether taint is prop-

agated. The recursive call in this case just needs a

single TA evaluation to return the tainted result. The

foreign function is then added as a source of taint and

the loop repeats. The ﬁrst TA evaluation now returns

the taint lists from source to the foreign function call,

and from the call to the subsequent sink. The prior se-

quence of TA evaluations must repeat one more time

before

L = L, calculating a least ﬁxpoint. The time

can be written in terms of calls to TA as

(d) = T

(1) = 3 + 3T

(0) = (3 + 3) (4)

The basis case T

(0) is of a foreign function that calls

no other foreign functions, requiring just one call to

TA, T

(0) = 1. Because there is a foreign function

call, taint analysis will still be called but just once.

We can generalize the time equation to n calls at ev-

ery depth (except for the last), and a maximum depth

of d:

(d) = (n + 2) +

∑

i=1

(i + 2)T

(d − 1) (5)

Noting that T

(d − 1) does not depend on i,

(d) = a(n) + b(n)T

(d − 1) (6)

where a(n) = n +2,b(n) =

n(n+5) The closed form

can be found by expansion of the geometric series:

(d) = a(n)

∑

i=0

b(n)

= a(n)

b(n)

d+1

− 1

b(n) − 1

(7)

The worst case complexity for MTA is polynomial in

n and exponential in d. If we modify MTA so that the

for C ∈ L loop never duplicates prior work, then the

time complexity drops to linear in n but exponential

in d.

(d) = (n + 1) + nT

(d − 1) (8)

If we include that the list of foreign function calls

available is ﬁnite and an assumption that calls are

distributed evenly over the source code then we can

approximate a bound on the exponential complexity.

Consider that there are a maximum of f foreign func-

tion calls and n calls in each monolingual program or

linkage program. Taking b(n) = n and one TA call

for each foreign function call (the ‘efﬁcient’ case in

eq. (8)), then we have that:

d+1

− 1

n − 1

≤ f (9)

Taking the log of both sides and assume that

log

d+1

− 1) ≈ log

d+1

) and log

(n − 1) ≈

log

(n), we have the approximation

d ≤ log

( f )

(10)

For example, if n = 20 and f = 400, then d ≈ 2.

4 IMPLEMENTATION

In this section we describe our intial implementation

of Algorithm 1. The implementation currently only

supports:

• C/C++ calling Python using python.h, and

• Python calling C/C++ using pybind11

ICSOFT 2021 - 16th International Conference on Software Technologies

Multilingual

Taint Analysis

Infer/Quandary

Pyt

Python.h

….

“PyObject_Call(“

….

pybind11.h

….

“clibrary.mul“

….

Monolingual Taint Analyzers

FFI Sources/Sinks

.c/c++,.h/h++ .py

Multilingual Code base

Python.h

Link File generator

pybind11

Link File generator

Figure 1: Multilingual Taint Analysis System Architecture.

This decision was made to allow timely performance

feedback on the MTA algorithm as there are many

public examples of Python/C/C++ code. Adding lan-

guages is just a quantitative, not qualitative, enhance-

ment to MTA.

MTA requires that we select a monolingual taint

analysis package for each supported language. We

elected to use Pyt (Thalman, 2016) for Python taint

analysis, due to our prior experience with it (Lyons

and Zahra, 2020), and Infer/Quandary for C/C++ taint

analysis. For efﬁciency reasons, the recursive MTA

algorithm shown in Algorithm 1 was reimplemented

as iterative. Figure 1 shows our system architecture.

Each supported language is associated with the fol-

lowing:

1. A monolingual taint analyzer (Fig. 1, lhs);

2. A set of FFI source/sink ﬁles and (Fig. 1, rhs/top);

3. A linkage program generator (Fig. 1, rhs/bottom).

4.1 Monolingual Taint Analyzers

The host source language is determined based on the

ﬁle name sufﬁx. A monolingual taint analyzer is

called by MTA for each a source ﬁle using a combi-

nation of user-supplied sources and sinks and the FFI

sources/sinks ﬁle. Monolingual taint can be detected

between sources and any of the user-supplied sinks as

would be expected. However, for any source traced to

an FFI sink, MTA begins its multilingual phase.

The linkage program generator is used to build a

standalone program in a guest language with a call to

the function identiﬁed in the FFI sink. The guest lan-

guage is identiﬁed based on which FFI sink was de-

tected. The linkage program constructor also identi-

ﬁes the guest language source ﬁle in the codebase and

ensures that the linkage program includes the source

ﬁle as part of its compilation unit.

MTA continues by invoking the guest language

taint analyzer on the linkage program in turn. Once

the analysis concludes, if taint was passed via the FFI

call to any variable involved in the call, then the FFI

call is added as a source of taint and the host taint

analysis is repeated.

4.2 Foreign Function Interface

The source/sink ﬁles for a taint analyzer indicate

which source code statements will signal that a vari-

able has become tainted (a source) and which state-

ments are to be monitored for reception of a tainted

value (a sink). All FFI API function calls are included

with the sinks.

There are two FFI interfaces in this implementa-

tion. The python.h FFI is relatively straightforward

and includes API calls such as “PyObject Call” and

others. Our main focus is on tracking taint through

user code. Some FFI API calls are required to set up

the arguments for the FFI, e.g., PyTuple SetItem. Be-

cause we are not interested in tracking taint through

system libraries at this point in our research, we

added dummy functions for these that always prop-

agate taint.

The pybind11 FFI is a little more involved, since

the guest language is hidden in a python module. The

existence of foreign function calls is determined by

a preliminary pass over the codebase that inspects

for the FFI C/C++ syntax. For example, function

“bar”, deﬁned by a “.def(“ pybind11 statement in

a ﬁle “foo.c++”, is written to the pybind11 FFI as

“foo.bar”. For this initial testing, it is assumed the

module will be imported without aliasing.

A Meta-level Approach for Multilingual Taint Analysis

#include ‘‘example.cpp’’ // guest fn defs

int main(){

double a1,a2,ret; // vars for args/reslt

a1 = taint(a1); // consider a1 tainted

ret = guestfunction(a1,a2); // function call

sink(a1); // is a1 still tainted

sink(a2); // was a2 tainted

sink(ret); // is ret tainted

return

}

Figure 2: Example Artiﬁcial Linkage Program.

4.3 Linkage Program Construction

The constuction of the FFI linkage program is similar

for all guest languages. The ﬁle consists of a main

program that includes the guest language source ﬁle

and calls the guest language function identiﬁed from

the host language taint analysis. An example is shown

in Fig. 2. Any argument to the guest function that was

tainted in the host program is speciﬁcally tainted by

putting them through a “taint()” function in the link-

age program. All the arguments and the function re-

turn are monitored by sending them to a “sink()” func-

tion in the linkage program. The sources/sinks ﬁle for

the guest taint analysis consists of the following:

1. the “taint(“ and “sink(“ statements,

2. any user-provided sources and sinks, and

3. the FFI sources/sinks for the guest language.

4.4 Example

An example multilingual system will serve to illus-

trate the operation of the MTA implementation. The

system consists of a web-based interface for a simple

matrix multiplication running on a Flask server. A

user types numbers into textﬁelds on the Flask-served

web page and clicks on a ‘multiply’ button, at which

point the resultant matrix is displayed. The back-end

is a Python program ‘main.py’ that receives the input

matrix data from the web page textﬁelds and returns

the result matrix for display. However, ‘main.py’ uses

a C++ implementation of matrix multiplication for ef-

ﬁciency. The source code for the Flask back-end is

shown on top in Fig. 3 and the C++ multiply on the

bottom. The FFI is pybind11.

The sources are the input from the web page via

Flask and the sink is the return to the web page via

Flask. A monolingual taint analysis would need the

source of matMul.multiply in Python, otherwise it

could not reliably trace taint through the multiply.

However, MTA recognizes the FFI as discussed in

section 4.2 and calls for a C++ taint analysis. A sepa-

rate linkage ﬁle, test run.cpp, is generated to include

Figure 3: Multilingual Taint Example. main.py (top), mat-

Mult.cpp (bottom).

just the call to the resolved FFI call, the C++ multi-

ply() function. If analysis of this reports taint prop-

agated then matMul.multiply is added as a source of

taint and the Python analysis is repeated.

For the purpose of presenting a deeper example,

let us consider further modifying multiply.cpp to call

a numpy matrix multiplication (instead of the C++

code shown in Fig. 4 bottom) using python.h, adding

an extra level of multilingual nesting to the system.

This modiﬁcation is shown in Fig. 4 where mat-

Mult.cpp now calls a numpy multiply in ﬁnal.py. The

analysis of this modiﬁed example diverges from the

prior example when the linkage ﬁle test run.cpp is an-

alyzed by Quandary. An additional FFI call is noted

(PyObject CallObject). The linkage ﬁle temp run.py

is constructed to call the resolved python function

pythFunc to determine whether taint is propagated.

Only if it is propagated will the analysis revert to that

of the prior example. The console output from MTA

for this analysis is shown in the Appendix.

5 RESULTS

This section presents the results from performance

testing of the MTA implementation. It begins by de-

scribing how the multilingual programs that comprise

the testing codebase were collected and then presents

the performance results.

5.1 Multilingual Codebase

The results in this paper were gathered by applying

the MTA implementation to Python and C/C++ pro-

gram which used the python.h and pybind11 FFIs.

An internet search was carried out for public github

repositories that met these constraints. The approxi-

mately 2000 repositories that were returned were fur-

ther restricted to those that called the guest language

ICSOFT 2021 - 16th International Conference on Software Technologies

main.py (start file)

src = list(request.form.to_dict().values())

ans = matMult.multiply(src)

return render_template(ans);

temp_run.cpp (calls multiply

from example.cpp)

vector<int> vec = taint({1, 2, 3})

vector<int> ans;

ans = multiply(vec);

PyObject *myResult =

PyObject_CallObject(myFunction, args);

ans = convertMyResult(myResult);

return ans;

matMult.cpp

matOne, matTwo = taint(matOne, matTwo)

matThree = final.pythFunc(matOne, matTwo)

temp_run.py (calls pythFunc

from final.py)

return numpy.multiply(args)

final.py

Figure 4: Multilingual Taint Example: FFI Calls.

Table 1: MTA Performance Analysis Codebase.

Total Num. of Repo. 20

Total Lines of Code (LoC) 1872

Average LoC/Repo. 94

Average Func. Calls/Repo 4.75

Average Forgn. Func. Calls/Repo 2.2

Max Forgn. Func. Calls/Repo 5

software as a function and those for which the guest

language function was not a class member (though

the remainder of the Python and C++ code could con-

tain and use classes). These were constraints of our

implementation. Finally duplicate or overly similar

examples were removed. The ﬁnal codebase included

20 multilingual software repositories.

Table 1 summarizes the 20 repositories. The

repositories included a total of 1,872 lines of code

in C/C++ and Python. The average repository con-

tained 2 to 3 source ﬁles (not including header ﬁles)

with an average of 94 lines of code. This made them

small enough in general to be checked by hand. The

largest was >400 lines of code. The average repos-

itory contained 2 or 3 foreign function calls and the

maximum seen was 5. The vast majority of FFI usage

was for Python calling C/C++ (18), the remainder be-

ing C/C++ calling Python (2) including 1 repository

that had both.

In general the processing of examples was com-

pletely automated. For example, the linkage ﬁles

were automatically generated in every case. How-

ever, in some few cases, source ﬁles were modiﬁed

by hand so that source code processing could occur:

For repositories that were libraries, a main program

was added to call the libary. For repositories that in-

cluded calls to binary libraries, when it could be done,

the library call was replaced with equivalent code. If

it could not be done, the repository was dropped from

the codebase. We view this manual intervention as

a short-term tactic to enable testing and not a long-

term characteristic of our approach; we believe these

changes, if they continue to be needed, could be auto-

mated in the long-term. Finally, as the objective was

to evaluate multilingual taint analysis, the main pro-

Table 2: MTA Performance Results.

Repo. Mono Mono Multi Multi Multi

Num. Taint Covrg Taint Covrg Impr.

1. 2 8 3 24 0.75

2. 2 6 3 33 0.85

3. 2 16 3 33 0.67

4. 2 8 3 33 0.8

5. 3 27 5 75 0.74

6. 2 6 3 12 0.67

7. 3 30 8 41 0.93

8. 2 10 3 18 0.64

9. 3 15 5 65 0.81

10. 2 6 3 18 0.75

11. 1 4 3 15 0.79

12. 3 18 5 70 0.80

13. 2 6 4 32 0.84

14. 2 6 4 32 0.95

15. 3 18 5 30 0.63

16. 1 3 3 9 0.75

17. 4 52 7 112 0.68

18. 2 8 3 15 0.65

19. 2 8 3 18 0.69

20. 3 18 5 145 0.89

gram in each repository was annotated to introduce

taint into an input variable that would eventually reach

the foreign function call.

5.2 Performance Results

The MTA performance results on the sample code-

base are shown in Table 2. The ﬁrst column indicates

the repository number. The second column indicates

the number of taint lists (source to sink) identiﬁed

with purely monolingual taint analysis. We calculate

a taint coverage metric as the length of the maximum

taint list times the number of taint lists returned. This

values both additional taints lists and longer taint lists.

The fourth and ﬁfth columns give this data for the

multilingual case. Finally we calculate an improve-

ment for multilingual taint analysis over monolingual

taint analysis as the multilingual coverage divided by

the sum of the mono- and multilingual coverages.

Table 2 shows that the improvement in coverage

is 63% or better in all the examples. It reaches as

A Meta-level Approach for Multilingual Taint Analysis

high as 95% for one repository (#14). Multilingual

analysis on average improves taint coverage by 76%

– showing that it opens up a signiﬁcant extra amount

of suspicious code for inspection.

6 CONCLUSIONS

This research has addressed the issue of taint analy-

sis in multilingual software systems. Although it is

increasingly common for software designers to select

different languages for different components of a sys-

tem (JavaScript for the front end, C/C++ for numer-

ical processing, etc.) taint analysis tools are primar-

ily language dependent. In contrast to other other re-

search on multilingual static analysis, our approach

does not privilege any language in the codebase above

any other. Our proposed solution to extending taint

analysis to multilingual systems includes monolin-

gual analysis and cross-language foreign function in-

terfaces (FFIs) as modular components.

The novel contributions of this paper include

the proposed Multilingual Taint Analysis algorithm

(MTA), an analysis of its complexity and a detailed

example, and performance results from our initial im-

plementation of MTA on a codebase of 20 reposito-

ries totalling 1872 lines of code. A coverage improve-

ment metric is introduced that reveals how much more

source code is opened to inspection for taint using

MTA. On average, coverage improvement was 76%

for MTA over monolingual taint analysis. The aver-

age repository size in this study was relatively small,

and this allowed detailed manual checking. However,

even with these small repositories, the improvement

in coverage is signiﬁcant. While we believe our re-

sults will transfer to larger repositories, that impor-

tant step is left to future work. Furthermore, the re-

sults hold for the C++/Python FFIs covered by the

implementation. While we argue that other FFIs can

be added with no change to our algorithm design or

complexity calculations, supporting evidence for this

is also a matter of future work.

The decision to concentrate on C/C++ and Python

was made based on the trend to embed C/C++ func-

tions in Python for speed of numerical processing.

While MTA clearly adds functionality in this case,

we believe that it holds even greater promise for

analysis of web repositories which include HTML

and JavaScript front ends communicating with back-

ends that may be built in Python. Both Python and

JavaScript leverage libraries that are written in other

languages. In future work we plan to address this

problem using the framework developed here.

ACKNOWLEDGEMENTS

The authors wish to acknowledge the contributions of

graduate students Kevin Johns, Courtney King, Ar-

lind Stafaj, Taylor Termine and Benjamin Vecchio.

REFERENCES

Alashjaee, A. M., Duraibi, S., and Song, J. (2019). Dynamic

taint analysis tools: A review. International Journal

of Computer Science and Security, 13.

Arzt, S. (2014). Flowdroid: Precise context, ﬂow, ﬁeld,

object-sensitive and lifecycle-aware taint analysis for

android apps. ACM SIGPLAN Conf. on Prog. lang.

Des. and Impl.

Boxler, D. and Walcott, K. (2018). Static taint analysis tools

to detect information ﬂows. Int. Conf. Soft. Eng. Re-

search & Practice.

Furr, M. and Foster, J. (2005). Checking type safety of for-

eign function calls. ACM SIGPLAN Conf. on Prog.

Lan. Des. & Imp.

Grimmer, M., Schatz, R., Seaton, C., Wurthinger, T., and

Lujan, M. (2018). Cross-language interoperability in

a multi-language runtime. ACM Trans. Prog. Lan. &

Sys., 40(2).

Kreindl, J., Bonetta, D., and M

ossenb

ock, H. (2019). To-

wards efﬁcient, multi-language dynamic taint analy-

sis. MPLR 2019, page 85–94, New York, NY, USA.

Association for Computing Machinery.

Kreindl, J., Bonetta, D., Stadler, L., Leopoldseder, D., and

ossenb

ock, H. (2020). Multi-language dynamic

taint analysis in a polyglot virtual machine. MPLR

2020, page 15–29, New York, NY, USA. Association

for Computing Machinery.

Lee, S., Dolby, J., and Ryu, S. (2016). Hybridroid: static

analysis framework for android hybrid applications.

31st IEEE/ACM Int. Conf. on Aut. Soft. Eng.

Lee, S., Lee, H., and Ryu, S. (2020). Broadening horizons

of multilingual static analysis: Semantic summary ex-

traction from c code for jni program analysis. 35th

IEEE/ACM International Conference on Automated

Software Engineering.

Lyons, D., Bogar, A.-M., and Baird, D. (2018). Lightweight

call-graph construction for multilingual software anal-

ysis. 13th Int. Conf. on Software Technologies.

Lyons, D. and Zahra, S. (2020). Using taint analysis and re-

inforcement learning (tarl) to repair autonomous robot

software. IEEE Workshop on Assrd. Aut. Sys.

Lyons, D., Zahra, S., and Marshall, T. (2019). Towards

lakosian multilingual software design principles. 4th

Int. Conf. on Software Technologies.

Madsen, M., Livshits, B., and Fanning, M. (2013). Practical

static analysis of javascript applications in the pres-

ence of frameworks and libraries. 9th Joint Meeting

on Foundations of Software Engineering.

Mayer, P., Kirsch, M., and Le, M.-A. (2017). On multi-

language software development, cross-language links

ICSOFT 2021 - 16th International Conference on Software Technologies

and accompanying tools: a survey of professional

software developers. Journal of Software Engineer-

ing Research and Development, 5.

Thalman, B. (2016). Pyt: A static analysis tool for de-

tecting security vulnerabilities in python web appli-

cations. MSC Thesis. Aalborg Univ. Denmark.

APPENDIX

Figure 5: MTA Taint Analysis of the Deeptaint Example

showing repeated calls to Quandary and to PyT.

A Meta-level Approach for Multilingual Taint Analysis