背景
Curl是从1998年开始开发的开源网络请求命令行工具,其中包含的libcurl也被作为组件广泛用于应用的HTTP请求。
10月4日,curl项目的作者bagder(Daniel Stenberg)在GitHub中预告将于10月11日发布 8.4.0 版本,并公开两个漏洞:CVE-2023-38545和CVE-2023-38546。其中 CVE-2023-38545是同时影响命令行工具curl和依赖库libcurl的高危漏洞,CVE-2023-38546是仅影响libcurl的低危漏洞。
截止当前还没有相关的漏洞细节公开,作者也认为噪声过多关闭了帖子的讨论。
图1:curl的开发者 bagder 预告漏洞
风险预估
curl的广泛使用
Curl从1998年维护至今,已经成为HTTP请求命令行工具的事实标准,具有丰富的 Api 和 Abi(应用程序二进制接口),因此被广泛应用于需要网络传输的产品或设备中,如手机/平板、操作系统、服务器、医疗和物联网设备等。
curl/libcurl 还广泛应用于以下方面:
- GitHub中有2.6万个相关的开源项目,墨菲安全分析发现其中php、shell、JavaScript、Python、C/C++项目中使用较多,在Java、Go、Ruby项目中使用较少;
图2:curl/libcurl相关不同语言的开源代码仓库占比
- 具有网络传输功能的客户端应用程序,如办公套件LibreOffice、火狐浏览器等;
- 几乎所有的操作系统,如:Linux、Windows、macOS、iOS 和 Android等。
漏洞利用可能性与危害
- curl/libcurl 是网络请求的客户端,不像服务端一样常驻,相比于服务端往往会有利用窗口限制。
- 从历史漏洞上看,curl较为重视安全,漏洞评级给大家的直观感受是偏高的,当然也由于CVSS强调的是对其本身的评级,并不用于体现在实际环境中的危害性。
- 从历史curl的漏洞来看,漏洞利用成本普遍较高,成功利用往往需要具有目标系统本地操作权限、特定的配置或用户交互等较高的前置条件。
- 过往高危漏洞主要是缓冲区溢出类漏洞以及协议实现层面的逻辑漏洞,漏洞危害可能导致远程代码执行或者泄漏请求和响应数据。
应对策略
由于目前漏洞细节并未公开,建议可以提前排查使用到了curl/libcurl的业务,在相关漏洞细节公开后进一步根据具体的利用条件排查和修复。
通过对curl和libcurl的引入方式和文件分析,我们梳理了排查方式供参考:
快速排查方式
curl
从引入依赖的方式来看,通常应用中会通过系统命令直接调用curl,例如在shell中通过调用curl进行http请求。
此时需要考虑系统发行版中自带的curl,以及应用中可以打包包含的curl文件。
curl -V
命令输出的banner信息可作为其特征:
$ curl -V
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
可以分别从进程和系统环境中排查:
- 对于系统环境中的curl,可以通过
curl -V | egrep -o '^curl [678]+.[0-9]+.[0-9]+'
获取对应的版本 - 对于进程中的curl,可以通过对文件进行识别,如
strings curl | egrep -o '^curl [678]+.[0-9]+.[0-9]+'
libcurl
在libcurl中也存在相同的特征:
CLIENT libcurl 7.44.0-DEV
libcurl/7.44.0-DEV
libcurl通常以动态链接库的形式存在,如libcurl.so.4.8.0
,应用依赖的libcurl,可能存在于系统lib目录,如/usr/lib/
,也可能被应用直接打包进应用目录。
因此排查需要考虑:
- 对系统lib目录及应用目录中的文件分析,如
strings libcurl.so | egrep -o 'libcurl[ -/]([678]+.[0-9]+.[0-9]+)'
- 运行中的应用可以通过分析进程打开文件来判断,如
sudo lsof | egrep -o '/.*.so.*' | xargs -I {} bash -c "strings {} | egrep -o 'libcurl[ -/]([678]+.[0-9]+.[0-9]+)'"
libcurl典型依赖分析
典型的,在c/c++中cpr、curlpp、crub等项目、python中的pycurl、ruby中的typhoeus都提供了libcurl的封装。
针对国内企业典型的CentOS系统+Java应用环境,我们进行了分析。
依赖了libcurl的rpm包
我们爬取了所有的Centos官方发布的rpm包,通过解析构建文件识别libcurl依赖。目前已知以下包依赖了libcurl,后续我们会持续更新:
perl-WWW-Curl
certmonger
qemu-kvm-ma
devtoolset-10-elfutils
gstreamer1-plugins-bad-free
ceph
dotnet
git19-git
mariadb-connector-c
amanda
ipa
dotnet3.1
aide
qemu-kvm
rh-mysql80-mysql
rng-tools
geoipupdate
xmlrpc-c
thunderbird
sblim-sfcb
rh-git227-git
python-pycurl
rust
httpd24-mod_security
git
rh-git29-git
libgit2
dotnet3.0
systemd
libopenraw
rpm-ostree
gcc-toolset-11-elfutils
gcc-toolset-10-elfutils
libreoffice
firefox
dovecot
curl
gstreamer-plugins-bad-free
libvirt
rh-git218-git
createrepo_c
httpd24-curl
elfutils
glusterfs
devtoolset-10-gdb
rsyslog
dotnet5.0
ceph-common
libcmis
flatpak-builder
libquvi
rh-passenger40-passenger
compat-exiv2-026
sssd
fwupd
vorbis-tools
librepo
strongimcv
ruby193-rubygem-passenger40
rh-nginx18-nginx
tpm2-tools
httpd24-mod_md
maven中央仓库中直接包含libcurl的组件
我们爬取所有的maven中央仓库组件的jar包、aar包,解压后判断是否包含了libcurl.so文件,目前已知存在少数的包将libcurl打包进其中(后续持续更新):
org.danbrough.kotlinxtras:curlLinuxX64Binaries
org.danbrough.kotlinxtras:curlLinuxArm32HfpBinaries
org.danbrough.kotlinxtras:curlAndroidNativeX64Binaries
io.dldb.sdk:dldb-lib-no-cpp-shared
io.dldb.sdk:dldb-lib
org.danbrough.kotlinxtras:curlAndroidNativeArm32Binaries
org.danbrough.kotlinxtras:curlAndroidNativeX86Binaries
com.amazon.alexa.aace:alexa
org.danbrough.kotlinxtras:curlLinuxArm64Binaries
com.qiniu:qplayer2-core
org.danbrough.kotlinxtras:curlAndroidNativeArm64Binaries
参考链接
- https://github.com/curl/curl/discussions/12026
- https://curl.se/docs/security.html
- https://daniel.haxx.se/blog/2021/12/03/why-curl-is-used-everywhere-even-on-mars/
本文转载自墨菲安全实验室,本文观点不代表墨知立场。