Julia security advisories

New to Julia
1

Hi folks,

How should I subscribe for Julia security advisories?

At the moment, I’m watching for updates to the Julia image on Docker Hub. I need to do better, both in terms of latency and detail.

Thanks,
Sheldon.

2

What kind of security advisories are you looking for? The Julia programming language, advisories for a given package…?

1 Like
3

See https://github.com/JuliaLang/julia/security

2 Likes
4

If you are interested in details:

Julia issues/pull requests - mentioning “security” AND sorted by: “recently updated”
( just create an RSS feed, you can expect lof of “noise” )

Example:

1 Like
5

less noise: label:security sort:updated-desc
https://github.com/JuliaLang/julia/issues?q=label%3Asecurity+sort%3Aupdated-desc

1 Like
6

I don’t see anything similar to Python Python : CVE security vulnerabilities, versions and detailed reports

Is understandable since there are currently “0 Published” security advisories. What to read into that, is this just a feature on Github that gets added automatically even if not (potentially) used?

From Julia’s Security Policy (at same place): “The LTS and current stable releases of Julia are the ones supported for security updates.” The current LTS is Julia 1.x and I would avoid that. While I do NOT know of any security issue there, I know bugfixes are no longer backported, last one was in March, but there are pending (bugfix) backports to 1.6 (and 1.7).

Julia is be safer than C (not saying much, as C isn’t, so much safer) and is as fast, also compared to C++, also safer (and faster) than most languages. But you want to keep it updated, e.g. not use Ubuntu’s snap install.

Some of the potential security issues are the responsibility of developers, e.g. Julia doesn’t validate UTF-8 input by default. Developers should to that (or e.g. your JSON library, I suppose such Julia libraries do). NOT validating can be a security issue, not just a regular bug. Julia has the option to do it for you and there’s an open issue about making the validation faster. Who knows if it will be a default later. I’m not sure what other languages do by default, but it seems like Java neither validates UTF-8, nor UTF-16 input, which can also be a security risk. Still, Java is considered a secure language.

Julia seems as secure as Java, assuming you run Julia-only code (when calling C or other languages, all bets are off, just as with Java and JNI, and it may be done more commonly with Julia), and given that you run julia --check-bounds=yes (in case you’re paranoid). Bound checking IS the default as in Java, it’s just that developers may selectively turn it off for performance gain.

There’s also the possibility of Julia using uninitialized memory, not done be default. That’s in the hands of the programmer with undef(I believe the user can’t turn it off), for performance gain. Integers can overflow however both in Julia (by default, there’s a package to avoid) and Java, unlike for (pure) Python, while can easily happen also in practice happen, e.g. with NumPy, or using the many extension modules commonly used.

While there are no CVEs applying to Julia directly, that I know of, some do indirectly, e.g. https://github.com/JuliaLang/julia/blob/master/deps/patches/p7zip-13-CVE-2017-17969.patch

I want to say security is taken seriously for Julia (I’ve seen evidence for that such as above, and there’s an email address to report) while I do not know of a similar document:

Public disclosure preferred
[…]
Private disclosure preferred

Note, you can search for the “security” label: Issues · JuliaLang/julia · GitHub

Currently 3 such issues are closed (and some code got backported to Julia 1.0.1) and 2 ae open, neither seem worrying to me, with one pushed to 2.0 milestone, and the other opened in April.

I do mention the label as it’s more targeted, the search for “security” text as opposed to label, has lots of noise, many open issues, but they shouldn’t be alarming (at least the number of issues). They’re just tech discussions as far as I can see, e.g. “The normal security policy for sudoers strips out all environment variables from all commands.” and “that would standardize creation of a security hole. Still, there are very legitimate uses for unchecked arithmetic” and:

I’m pretty strongly against putting any kind of executable code in this kind of config file. […] For one thing, it would make this file a security attack vector :grimacing:.

Some issues are relevant, and I would like to see this one closed quickly (there’s already a PR), should probably have the label “security”:

There are lots of other labels, such as “existential crisis” with only one issue, that is open. It may have been applied sarcastically?At least it’s not (also) a security issue.

5 Likes
7

Thank you for the detailed response. I think you’ve provided a great summary of the concern I have, along with the problems with each of the available information streams.

When my head of security asks me what I have done to ensure that I will be notified of (and will respond to) the discovery of vulnerabilities in Julia, the standard library and the specific packages that we use, I don’t know what I’ll say.

8

So far, no CVEs or similar (that I know of) have been filed for julia or code written in julia, so this is untested ground. If your head of security is concerned about every piece of code you’re using, I suspect you’re under strict government or legislative requirement to check for such things. If this is part of a defense in depth strategy, I’d assume regular audits of your own code in regards to handling of untrusted user input would be appropriate as well (and if vulnerabilities in imported libraries are found as part of this process, reporting them upstream would certainly be appreciated!).

That being said, a lot of julia packages (as far as I can tell) do not have an explicit newsletter or email address to subscribe to. This is simply due to the fact that there’s no one central julia organization taking care of such matters (and so far this hasn’t been a focus for the core language, though security@julialang.org and the advisory section on github exist) as well as most packages being centered on “compute”, not on data management. In that regard, the situation is no different from other open source programming languages and libraries written in them.

The safe-by-default nature of julia makes it kind of hard to get something like remote code execution (unless you’re explicitly doing something bad, like using eval on untrusted user input). Julia also isn’t high-profile enough yet to have received an audit and because such projects are usually rather expensive, it’s not likely that one would happen out of the blue.

All in all, I’d suggest to do the same things you’d do with other languages - subscribe to their release notes (since most packages are hosted on github, closed issues and merged pull requests as well as a diff are automatically available), check for security relevant changes and act based on them. I don’t think this is fundamentally different in julia compared to other languages.

1 Like
9

I am not sure what qualifies as a “vulnerability” in this context. The language, Base, the standard libraries and most nontrivial packages have bugs all the time. If you are running a web service using Julia with unsanitized input, it is conceivable that they could be exploited for some purpose. So… just don’t do that in a sensitive environment.

If you are using Julia like most people do (scientific programming), it is unclear how bugs would become vulnerabilities. You need to share more details about what you are doing with Julia to get help about potential attack vectors and containment options. CVE-style vulnerabilities are not a really good match for this purpose.

3 Likes
10

Well, you shouldn’t do that. :slight_smile: I doubt you’re less safe with Julia than for most other languages (or at least code in general based on C or C++), assuming you’re not using an outdated software. E.g. PostgreSQL database advises you to use the latest point version of the stable/major version you’re using, i.e. should always be safer to do a minor upgrade. I think that’s the case too with Julia.

All software has bugs, while not all bugs lead to security vulnerabilities (and non-default julia --check-bounds=no helps and should be fast enough for user interface software). You should be using, to prevent SQL injections:

That package doesn’t seem to also validate that your strings are valid UTF-8 however. Maybe it should, and I think you simply do it with isvalid(my_string). It’s probably best, and still needed, to do it earlier on input, in the user interface AND on server if the former is in JavaScript. In case people forget, I think it might still be valuable to do redundantly, second or third time in SQLStrings.jl.

[In other context, SQLdf.jl seems cool.]

Note, e.g. Plotly’s Dash is supported for Julia by the company. I was hoping it takes care of validating input:

but it doesn’t seem so (hopefully outdated info), at least not the core JavaScript that uses React (nor Python?), so I doubt the official Dash.jl does either:

I’m not sure what it’s competitor Stipple.jl from @essenciary does or his Genie.jl. Maybe it should?

I did try to find CVEs related to Dash, and found something, unclear what it referred to, but note I tracked down it’s for different unrelated dash software: CVE - CVE-2009-0854

Plotly has suspiciously only one CVE (or the software really this good): Plotly Plotly.js : CVE security vulnerabilities, versions and detailed reports

11

Do you have a source for this?
As far as i know bugfixes are still back ported to the LTS, as required.
It is just that none have been required.
Likely due to a combination of the LTS not having many bugs anymore, and people not using the LTS any more and thus not requiring things to be bugfixed.

12

Yes, this was cancelled:

https://github.com/JuliaLang/julia/pull/34011#issuecomment-751992550

I guess a known security issue might change this (or is #34319 an exception? I guess certificates do not affect users, only developers).

13

Here’s a concrete example: https://github.com/JuliaLang/julia/pull/42918

That’s a fix for CVE-2021-42574 and CVE-2021-42694.

How should I subscribe for whatever notifications will be published when this fix is released in Stable and LTS?

2 Likes
14

AFAIK the Julia project does not publish it’s own notification feeds of any form for anything.
It has release notes you can check, and everything is on github.
(Except for things that are embargoed, but I assume once resolved they end up there, right?)

Since everything is on github, that does mean you can use a Github->RSS generator

3 Likes
15

Thanks, Lyndon. That seems like the best I can get at this time.

16

I was going here to post this PR (but you beat me to it), note the issue also applying to other languages, it’s very devious:

It’s good to know Julia developers are on top of things. The fixed is merged, but not yet released to the public, is in 1.6.4 and 1.7-rc3. It IS in “Backports for julia-1.6.4 #42147” while listed under “Non-merged PRs with backport label”, but that’s a false-alarm, I confirmed.

It’s good to know the developers are even checking the package ecosystem with PkgEval. That also threw up a lot of false positives, no true positives that I know of, I doubt there are exploits in Julia code, but can’t rule it out…

If you’re really paranoid you should run your code with 1.6.4 or 1.7-rc3 or later. I believe you can access such builds already even though they are not on the download page. The master -DEV version is there and it would have the fix.

Let’s say you run your code on master, can you then assume it’s safe for 1.6.3? Since this is a parser issue, you should get failures if some code had an exploit, ASSUMING all your code gets parsed on master. As far as I understand you don’t need to run all your code paths (and it’s not possible to try, because of the theoretical halting-problem). But would you also know for sure that all your code got parsed? Since Julia is a dynamic language, you could generate new code at runtime, that then gets parsed (and compiled). I suppose if you worry about that too, then you might also have problems this fix couldn’t handle.

17

Note that that exploit has been known for decades (but no one had opened a fancy website with a cool name) and the world has survived so far:

4 Likes
18

Here’s our security page on github:

https://github.com/JuliaLang/julia/security/policy

6 Likes
19

Thanks, Viral.

When do you think CVE-2021-4048 will appear there?

20

CVE-2021-4048 Timeline

Community members found the issue and fixed it upstream.
Julia’s dependency has also been updated later.

Both LTS 1.6.4 and 1.7.0 are safe.

2 Likes