Potential secutiry vulnerabilities in the C libraries which mip depends on. Can you help upgrade to patch versions?

[MikeWazoWski123]

Hi, @h-g-s , @tuliotoffolo , I'd like to report a vulnerability issue in mip_1.13.0.

Dependency Graph between Python and Shared Libraries

Issue Description

As shown in the above dependency graph(here shows part of the dependency graph, which depends on vulnerable shared libraries), mip_1.13.0 directly or transitively depends on 42 C libraries (.so). However, I noticed that one C library is vulnerable, containing the following CVEs: libtinfo.so.5from C project ncurses(version:5.9) exposed 3 vulnerabilities: CVE-2019-17595, CVE-2019-17594, CVE-2021-39537

Suggested Vulnerability Patch Versions

ncurses has fixed the vulnerabilities in versions >=6.3

Python build tools cannot report vulnerable C libraries, which may induce potential security issues to many downstream Python projects. As a popular python package (mip has 69,109 downloads per month), could you please upgrade the above shared libraries to their patch versions?

Thanks for your help~ Best regards, MikeWazowski

[sebheger]

Hi Mike,

thanks for your post and for taking care of potential security issues. As I am not an expert, I try to involve someone who is more in the details.

@tkralphs Is that a potential security issue for CBC in common or only related to the python-mip build process?

[tkralphs]

If I finally understood correctly, this has nothing to do with Cbc per se. It has to do with the fact that an old version of the shared library libtinfo is being distributed as part of the mip package. If you look at the contents of the installed package, you can see that library in the libraries/lin64 directory. It is an old version because the way these libraries were produced was by building on an older Linux image in order to ensure compatibility with newer libc versions (and hence libraries that should work in almost any Linux).

There is an easy fix in principle: libtinfo is a dependency of libreadline and there is no reason at all to build Cbc with readline support enabled, since that is only useful for the interactive shell of the command-line executable (as an aside, since libreadline is under the GPL, distributing a version of Cbc that uses it in binary form is technically a license violation). The Cbc libraries need to be rebuilt without a dependence on readline. The right way to do this would be to just abandon the current packaging and switch to using cibuildwheels, as described in #262.

[MikeWazoWski123]

@tkralphs , thank you very muck for your feedback. I can understand, this is a tradeoff between compatibility and security.

By the way, is the diagnosis information useful to you? I am happy to know that :) Our team developed a tool that can detect the vulnerablity issues that are induced by cross-language invocations. If you are interests, I can share you a download link when we make it open-source.

[tkralphs]

@MikeWazoWski123 To be honest, my first reaction was that this report was some sort of self-promoting SPAM that could probably be safely ignored. Once I dug in, I had a hard time actually understanding what the diagnosis was from the report because the offending library is only a secondary dependency. There is also a lot of mention of ncurses, which seemed to be a red herring at first. The thing that finally allowed me to understand was the dependency graph, which shows that the library with the actual security issue is a secondary dependency through libreadline and (I suppose) is a library that is part of ncurses. All in all, it was not that easy to parse the provided information, but that may be because of the particulars of this case and/or my lack of knowledge. Honestly, I don't think this tool is something I personally would find useful, but I could see it being useful to others.

[sebheger]

@MikeWazoWski123 Will you check if for the new release there is still a security issue?