一例共享库文件被修改的定位分析

机器环境：centos 6.5 

发生背景：为了修复libvirt1.2.5的一个bug，修改了源码并重新编译，替换/usr/lib64/libvirt.so.0.1002.5文件，编译生成的so文件大小为3407432字节，但是第二天，文件大小却变为3411576字节，文件被莫名修改。

 

问题定位：

1、文件对比：对比变化后的的文件和变化前的文件【为了便于分析，提取了变化的so文件到tmp目录】

       对比sections headers：

       readelf -S  /usr/lib64/libvirt.so.0.1002.5

       readelf -S  /tmp/libvirt.so.0.1002.5

       对比截图如下：

可以看出，修改后的so文件多了三个节区：.gnu.liblist、.gnu.libstr以及.gnu.prelink_undo

另外每个节区的地址发生了变化，相对之前出现固定的偏移。从直观上看，似乎是因为某个程序对这个so文件做了模式化修改。

 

2、尝试监控文件变化：为了定位出是哪个程序对文件进行了修改，事先将被篡改的文件恢复为原状，即3407432字节的那个版本。然后利用auditctl监控文件变化：

auditctl -w /usr/lib64/libvirt.so.0.1002.5  -p wa -k libvirt_mon 【此处只监控写】

•-w 指明要监控的文件

•-p awrx 要监控的操作类型，append, write, read, execute

•-k 给当前这条监控规则起个名字，方便搜索过滤

查看修改纪录：ausearch -i -k libvirt_mon，生成报表 aureport.

当天并未监控的文件变化，等待第二天继续观察

 

3、监控结果分析

第二天，文件大小果然发生变化，用ausearch -i -k libvirt_mon查看监控日志:

可以看出是prelink命令对so文件做了修改，但是不知道prelink是什么情况下才调用的，搜索一下/etc目录，看看是否是计划任务，执行grep -rn  'prelink' /etc，结果发现可疑文件：

可以看出/etc/cron.daily下面有个prelink脚本：

该脚本调用了prelink命令，和之前监控的结果一致。再看/etc/anacrontab

上面START_HOURS_RANGE=3-22，定义任务是从3点开始执行，再联系前面的监控结果，是3:20被修改，符合预期。

 

4、prelink知识扩展

Prelink是Red Hat 开发者 Jakub Jelinek 所设计的工具，正如其名字所示，Prelink利用事先链接代替运行时链接的方法来加速共享库的加载，它不仅可以加快起动速度，还可以减少部分内存开销。

借用man手册上的一段描述：

DESCRIPTION

prelink  is  a  program  that modifies ELF shared libraries and ELF dynamically linked binaries in such a way that the time needed for the dynamic linker to perform relocations at startup significantly decreases.  Due to fewer relocations, the run-time memory consumption decreases as well (especially the number of unshareable pages). The prelinking information is only used at startup time if none of the dependent libraries have changed since prelinking; otherwise programs are relocated normally.

prelink first collects ELF binaries to be prelinked and all the ELF shared libraries they depend on. Then it assigns a unique virtual address space slot to each library and relinks the shared library to that base address.  When the dynamic linker attempts to load such a library, unless that virtual address space slot is already occupied, it maps the library into the given slot.  After this is done,prelink, with the help of dynamic linker, resolves all relocations in the binary or library against its dependent libraries and stores the relocations into the ELF object.  It also stores a list of all dependent libraries together with their checksums into the binary or library.  For binaries, it also computes a list of conflicts (relocations that resolve differently in  the  binary’s  symbol  search scope than in the smaller search scope in which the dependent library was resolved) and stores it into a special ELF section.

At runtime, the dynamic linker first checks whether all dependent libraries were successfully mapped into their designated address space slots, and whether they have not changed since the prelinking was done.  If all checks are successful, the dynamic linker just replays the list of conflicts (which is usually significantly shorter than total number  of  relocations) instead of relocating each library.