【项目实战】Linux共享库交叉编译选项引起的安全扫描问题与解决方法

本文约1100字，安全漏洞问题终于快要解决完了，本文整理了最近遇到的共享库编译的问题和解决方法。为了解决这些大批量安全问题，除了常规手段，真是用了不少“偏方”。

关注公众号, 即可获得与Linux相关的电子书籍以及常用开发工具，文末有文档清单。

emba安全扫描工具扫出来的问题如下图所示，红色部分必须消除，变成绿色为正常状态。

先来分析上面图片的表中每个扫描项目的含义及产生的原理并提供解决方法如下：

1.common linux file: no

含义：这个文件不是标准的Linux系统文件

产生的原理：

工具会对比已知的Linux标准文件数据库（如通过包管理器安装的文件列表）

或者检查文件路径是否在标准目录中（如 /lib、/usr/lib、/bin、/sbin）

如果不在已知列表中，就标记为"no"

例如针对libhandwrite.so，这通常表示它是：第三方库、应用程序自带的库、自定义开发的库。

2. CWE_CNT: 0

含义：常见弱点枚举（Common Weakness Enumeration）计数为0

产生的原理：工具对二进制文件进行静态分析

扫描已知的安全漏洞模式，如：

缓冲区溢出、格式化字符串漏洞、使用不安全的函数（如strcpy、gets等、与CWE数据库进行模式匹配

其中0表示在当前扫描级别下未发现已知CWE漏洞

注意：这不代表绝对安全，只表示未发现工具已知的漏洞模式

3. RELRO: No RELRO

含义：重定位只读（Relocation Read-Only）保护未启用

产生的原理：通过检查ELF文件的程序头（Program Headers）和动态段（Dynamic Segment）

具体检查：

# 通过readelf检查

readelf -d libhandwrite.so | grep BIND_NOWreadelf -Wl libhandwrite.so | grep GNU_RELRO

No RELRO 意味着：

全局偏移表（GOT）在运行时是可写的

攻击者可能通过GOT覆盖进行攻击

修复方法：编译时添加 -Wl,-z,relro或 -Wl,-z,relro,-z,now

4. NX state: NX enabled

含义：非执行位（No-eXecute）已启用

产生原理：检查ELF文件的程序头中的段权限

具体检查：

readelf -Wl libhandwrite.so | grep GNU_STACK

# 如果有RWE权限，NX disabled；如果只有RW权限，NX enabled

NX enabled 意味着：

数据区域（如栈、堆）不可执行、防止代码注入攻击

这是通过编译选项 -z noexecstack实现的

如上的这些问题，需要在我们的库和可执行文件的Makefile中增加如下编译选项：

CFLAGS += -Wall -g -rdynamic -funwind-tables -ffunction-sections -fPIE -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-allCXXFLAGS += -Wall  -g -rdynamic -funwind-tables -ffunction-sections -fstack-protector-all LDFLAGS += -shared -Wl,-z,noexecstack,-z,relro,-z,now

特别说明：

共享库链接配置，如果编译可执行文件用-pie

LDFLAGS += -pie -Wl,-z,noexecstack,-z,relro,-z,now

共享库链接配置，如果编译成共享库则配置成-shared

LDFLAGS += -shared -Wl,-z,noexecstack,-z,relro,-z,now

针对NO RELRO这个问题，通过readelf -l xxx.so指令来查看增加了上文LDFLAGS中的编译选项后是否包含了GNU_RELRO，如下所示：

修改完再用扫描工具扫就会程序绿色状态,如第一张图片的libcommon.so库的状态。