Skip to main content

Python Package Installation: to sudo or not to sudo

Python programming language is having an increasing presence in IoT projects. According to a survey of IoT developers conducted in 2016, python is among the top 4 languages they use in their projects. One of the benefits of using python is its variety of powerful packages, which can easily be installed. The very same characteristic, however, could introduce security challenges. In this blog, we discuss how improper python package installation can introduce security risks and look into some examples.


Python packages are created and maintained in an open-source fashion, where the community publishes packages on Python Package Index (PyPi) website. Some malicious people, however, use this ecosystem to trick python programmers and compromise their security.
 

Typically, installing python packages starts with the command pip install [package-name], which often throws an error on not having enough permissions to complete installation.

The next option for many people is to choose one of the following:

sudo pip install [package-name]
or
pip install --user [package-name


To motivate the topic of this blog, we first gauge which command our classmates use in a poll:





 The claim is that using sudo with python package installation is a bad practice in terms of security. To understand why, we need to understand the basic structure of python packages, as shown in the figure below.




When installing a package, the file setup.py is executed. Now, one could include malicious code in that file and compromise the system when give root access.  As demonstrated in class, we were able to remove some root-owned folder by just installing a python package with root privileges. The figure below shows the malicious content of our setup.py.



Example attacks:

Malicious Packages: Packages specifically written to compromise user information or system. Inexperienced users may fall for these traps.

Typosquatting: Packages with names extremely similar to legitimate packages. Users can fall for this trap by simply mis-spelling the installation command.

Unintentional Vulnerabilities: Packages with design issues, which could unintentionally cause compromise in end-users’ security.


The table below shows a few malicious packages that were exploiting using typosquatting.

As a specific example, let's consider the colorama vs. colourama incident. Colorama is a python package for adding colors to windows terminal. On the other hand, hackers developed colourama (British spelling) to install a script on the victim's computer. The script would replace every bitcoin link in the clipboard with the bitcoin link of the malicious developer, redirecting money to the malicious person's account.




The conclusion of this blog is the following: the safer option for installing python packages is to use pip install --user [package-name].



Comments

Popular posts from this blog

Angr: A Multi-Architecture Binary Analysis Toolkit

This blog is quoted from several angr blogs and documentations, click  here  and  here . angr is a multi-architecture binary analysis toolkit, with the capability to perform dynamic symbolic execution (like Mayhem, KLEE, etc.) and various static analyses on binaries. We've tried to make using angr as pain-free as possible - our goal is to create a user-friendly binary analysis suite, allowing a user to simply start up iPython and easily perform intensive binary analyses with a couple of commands. That being said, binary analysis is complex, which makes angr complex. This documentation is an attempt to help out with that, providing narrative explanation and exploration of angr and its design. Several challenges must be overcome to programmatically analyze a binary. They are, roughly: Loading a binary into the analysis program. Translating a binary into an intermediate representation (IR). Performing the actual analysis. This could be: A partial or full-prog...

Introduction to Meltdown and Escaping the Chrome Sandbox

R untime isolation and sandboxed environments are central to modern application security, but the most commonly used ones may not be as secure as we hope. Overview The general idea of isolated or sandboxed environments is to give a program a limited scope in which to operate. Instead of allowing a given program to use any of a machine’s resources, physical or virtual, you restrict its environment such that it can only access aspects of the system that the sandbox designer has decided are available for use by the program. This is not unlike putting your child in a literal sandbox with high walls – they are free to do whatever they want with all the sand, toys, and tools inside, but cannot interact with the environment outside. Isolation principles are in play at pretty much every aspect of modern computing. For example, last week a classmate wrote a blog on WannaCry, an exploit in Windows SMB older and unpatched versions of Windows. Without going into the detail...

Foreshadow: Breaking SGX Confidentiality

Attack Overview   Speculative execution  has been a widely reported and studied vulnerability that focuses on violating memory isolation. For a while Intel’s SGX was thought to be safe from speculative execution,  but  recent research has shown that  this  is not the case. The Foreshadow attack  is capable of violating  all security assumptions surrounding intel SGX and requires a true hardware level patch to fix.   Foreshadow is an extension upon Meltdown which allows SGX memory to sit unprotected in the cache. The key to defeating SGX’s protections lies in abusing the legacy permission checks which occur before SGX can implement its own protections. Originally, SGX was thought to be secure as when an invalid memory access occurs all data gets overwritten with a dummy value of –1. This behavior is called “abort page” semantics. In order to defeat this protection, we need to cause a “page fault”. A page fault is part of the legacy...