martin f krafft wrote: > If you install a third party deb, you should inspect its contents > exactly to make sure it doesn't touch files in /etc. Also check the > hooks. If there are no problems, then it's probably safe. Did you know that dpkg will not install /var/lib/dpkg/info/* if it's in the package's data.tar.gz? I'm sad that I cannot give that as an example of an attack such checks will miss, but including files in /dev/* is nearly as much fun. /proc/acpi/sleep is an amusing file to ship in a deb too. If you want to run arbitrary code, you need to be more sneaky.. Shipping a /root/.bashrc or /usr/local/bin/cat is too obvious, instead you can ship a /lib/i486-linux-gnu/somelib.so. (The linker won't use it until something else eventually runs ldconfig but this just hides that your package is what causes the eventual breakage.) Be sure to include some /var/run/*.pid files, with a pid of 1 of course, so that stopping daemons causes the system to reboot. Including a /tmp/.X11-unix/X0 will mess up the running X nicely. BTW, including /bin/sh in a package won't work due to overwrite checking, but you can include /usr/bin/awk and replace the symlink to alternatives, since that symlink is not in a package. Finally, installing a 'sl' or other typo-squatting command is always an option. If these examples didn't make sense to someone, don't install third party packages from untrusted sources, no matter how much checking you do.. -- see shy jo
Attachment:
signature.asc
Description: Digital signature