PO Box 1214 • La Pine • Oregon • 97739 • 541-410-2760

 

M
a
i
n

Home

  • Tech Notes
  • Showcase
  • What We Do
  • Downloads
  • Store
  • IMO
  • Contact Us
  •  
    Inspecting a Debian / Ubuntu Package

    Inspecting a Debian / Ubuntu Package

    In this day and age software and even data has become a dangerous thing. I'm focusing on software for this article. The current state of software requires that we be very cautious about what and how we install it. I was recently looking for an upgrade on a program I use and thought I'd check their site for the latest. Turns out they only ship software in DEB or RPM for Linux, no binary tar balls. In the past I'd be delighted to install ".deb" packages. If I get a program in source or binary tar-ball I make a ".deb" out of it. BUT what happens if you want to inspect it before you install it?

    NOTE: For the sake of this discussion I'm going to call all forms of software distribution a "package" regardless of how I get the file: source / binary tar-ball, RPM, deb, ZIP, ...

    My big concern is that the time my computer is most vulnerable to malware is when I do things like "sudo make install" or "sudo dpkg -i". That's the one time the package is likely to have full root access to my system. At any other time it only has access as me, which since I don't run as "root", means its up against the same safety net that I work in every day. The most it can do is cause damage to my files and masquerade as me. But with "root" access it can do virtually anything to my system, including reflash my MoBo's BIOS, which apparently is happening, thanks to poor hardware engineering choices and UEFI. And that rabbit trail is for another article.

    There are a few tools out there that let you peek inside a ".deb" but most only show or extract the file content. A ".deb" is an "ar" archive with a couple of tar-balls in it. See "man deb" for the gory details. One of them is the installed file tree and the other contains the "control" file tree, which is the part you don't ordinarily get to see. Its not just the package "meta data", like: name, description, ... but there are also "maintainer scripts" in here. These scripts get run as root and are ordinarily invisible. They are free to perform any mayhem they wish.

    With that information even someone without a Debian derivative installed can open and examine the content of a ".deb". And for the non-Debian inspectors, out there, I'm sure that that man page is on the interweb somewhere. ;-) But for those of us that are using Debian / Ubuntu / Devuan derivatives we have a simpler alternative. "dpkg-deb"! So download the package your interested in and follow along. I downloaded Pencil v3.1.0 since I was hoping for an upgrade. Then I did the following:

    $ dpkg-deb -R pencil_3.1.0.ga_amd64.deb pencil
    $ ls -l pencil
    total 12
    drwxr-xr-x 2 jon home 4096 Oct 18  2019 DEBIAN
    drwxr-xr-x 3 jon home 4096 Oct 18  2019 opt
    drwxr-xr-x 3 jon home 4096 Oct 18  2019 usr
    $ ls -l pencil/DEBIAN
    total 20
    -rw-r--r-- 1 jon home  437 Oct 18  2019 control
    -rw-r--r-- 1 jon home 5233 Oct 18  2019 md5sums
    -rwxr-xr-x 1 jon home  387 Oct 18  2019 postinst
    -rwxr-xr-x 1 jon home  266 Oct 18  2019 postrm

    OK! That first line does all the actual work and extracts the content. The rest is for illustration. "$" just illustrates the prompt. My package file name was "pencil_3.1.0.ga_amd64.deb" and I extracted the "raw" (-R) content into a directory named "pencil". I list the content of the top folder so you can see an example of the content. I then listed the "control" files, which are stored in the directory "DEBIAN". Any other directories extracted are the actual package content that more or less gets stored in your file system (in this case: "opt", "usr").

    NOTE: the "control" file are typically renamed and installed into "/var/lib/dpkg/info".

    In my case I looked over the scripts in "DEBIAN" and saw that although there were some bad developer moments, there wasn't anything nefarious. I browsed over the remaining content and it looked typical of what a Chromium based app looks like. Of course at this point the truly paranoid might want run various malware detection tools on the extracted content.

    I've been using this software package for a while so I'm fairly confident its not malware in disguise (trojan horse). With a lot of what's going on today this is not necessarily the safest assumption, but it is one I'm making at this time. I would like to test drive it though, before I actually install it. So I wandered the package content and found the ".desktop" file to determine how it launched itself. And I did this:

    $ cd pencil/opt/pencil-3.1.0.ga/
    $ ./pencil
    ./pencil: /lib/x86_64-linux-gnu/libdbus-1.so.3: no version information available (required by
    ./pencil)
    [17951:0429/103953.872508:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary
    was found, but is not configured correctly. Rather than run without sandboxing I'm aborting
    now. You need to make sure that /u/home/jon/tmp/pencil/opt/pencil-3.1.0.ga/chrome-sandbox is
    owned by root and has mode 4755.
    Trace/breakpoint trap

    Hell no! I'm not OK with the risk of allowing this program to run as root all the time. That's an unacceptible level of risk for me and a "dream come true" for malware authors. This may be normal behavior for Chromium packaged apps but "root access" is totally unacceptible for an app used to make drawings. Beware of giving unneeded permissions! it just opens doors to hackers.

    Well I just saved myself from a huge potential problem by inspecting before trusting. This program is not getting installed. I'll have to find another tool as time permits.