showmount代码内存泄漏

最新推荐文章于 2024-10-24 17:32:41 发布
最新推荐文章于 2024-10-24 17:32:41 发布
阅读量1.8k 收藏 1
点赞数
文章标签： reference centos struct null string leak
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/fjhjsjy/article/details/7928080
版权
本文通过使用valgrind工具发现并修复了一个NFS服务检测模块中的内存泄漏问题，涉及clnttcp_create、authunix_create_default和xdr_exports等函数的资源释放。
摘要由CSDN通过智能技术生成
最近重构NAS存储的程序，发现程序总是在运行1天多后因为oom被kill。开始觉得很奇怪，因为担心有内存碎片，程序里面用到的内存都不是动态申请的，怎么会有内存泄漏呢？内核消息和top监控的结果都显示确实存在内存泄漏，只好逐个线程检查。检查到NFS服务检测线程的时候出现了异常情况，用valgrind检测NFS服务检测模块居然有内存泄漏。这个结果更加让我诧异，检测模块的代码是从showmount源码中提取出来的。
首先我怀疑是不是我提取代码的时候有什么问题，于是又把我的代码和showmount的代码（1.0.9版本的nfs-utils）重新核对了一遍，除了省略了使用clnttcp_create而直接使用clntudp_create创建RPC客户外，与showmount的执行流程没什么区别。
我使用的代码如下（使用//注释的代码是修正内存泄漏问题添加的代码）： 
WIS_BOOL NSIA_DISK_CheckNFSService(WIS_CONST WIS_U32 u32DiskIp,
                        WIS_S8 * WIS_CONST ps8ShareDir)
{
	enum clnt_stat      enClntStat;
    struct sockaddr_in  stServerAddr;
    struct timeval      stPertryTimeout;
    struct timeval      stTotalTimeout;
    CLIENT              *pstClient = WIS_NULL;
    exports             stExportList;
//    exports             stExportList2;
    WIS_S32             s32Sock;


    /* init rpc handle, use udp only */
    stServerAddr.sin_addr.s_addr = u32DiskIp;
    stServerAddr.sin_family      = AF_INET;
    stServerAddr.sin_port        = 0;
    s32Sock = RPC_ANYSOCK;


    stPertryTimeout.tv_sec  = 1;
    stPertryTimeout.tv_usec = 0;
    if ( (pstClient = clntudp_create(&stServerAddr, MOUNTPROG, MOUNTVERS, stPertryTimeout, &s32Sock)) == WIS_NULL )
        return WIS_FALSE;


    pstClient->cl_auth = authunix_create_default();


    stTotalTimeout.tv_sec   = 2;
    stTotalTimeout.tv_usec  = 0;


    memset(&stExportList, '\0', sizeof(stExportList));


    enClntStat = clnt_call(pstClient, MOUNTPROC_EXPORT, (xdrproc_t) xdr_void, WIS_NULL,
			            (xdrproc_t) xdr_exports, (caddr_t) &stExportList, stTotalTimeout);


//    stExportList2 = stExportList;


    if (enClntStat == RPC_SUCCESS)
    {
        while (stExportList)
        {
            if ( strcmp(ps8ShareDir, stExportList->ex_dir) == 0 )
            {
//                xdr_free((xdrproc_t) xdr_exports, (caddr_t) &stExportList2);
//                auth_destroy(pstClient->cl_auth);
//                clnt_destroy(pstClient);
                return WIS_TRUE;
            }


            stExportList = stExportList->ex_next;
        }
    }


//    xdr_free((xdrproc_t) xdr_exports, (caddr_t) &stExportList2);
//    auth_destroy(pstClient->cl_auth);
//    clnt_destroy(pstClient);
    return WIS_FALSE;
}

于是直接用valgrind检测showmount程序： 
valgrind --tool=memcheck --leak-check=full --leak-resolution=high --show-reachable=yes --track-origins=yes /usr/sbin/showmount -e 172.18.13.245


结果居然是：

==4142== HEAP SUMMARY:
==4142==     in use at exit: 8,737 bytes in 11 blocks
==4142==   total heap usage: 15 allocs, 4 frees, 9,721 bytes allocated
.........
==4142== LEAK SUMMARY:
==4142==    definitely lost: 24 bytes in 2 blocks
==4142==    indirectly lost: 8,697 bytes in 8 blocks
==4142==      possibly lost: 0 bytes in 0 blocks
==4142==    still reachable: 16 bytes in 1 blocks
==4142==         suppressed: 0 bytes in 0 blocks

showmount申请了15次内存，只释放了4次，有8KB多内存没有释放。从valgrind的详细结果可以找到哪些函数动态申请的内存没有是否： 

==4142== 8 bytes in 1 blocks are indirectly lost in loss record 1 of 11
==4142==    at 0x4804EC2: calloc (vg_replace_malloc.c:418)
==4142==    by 0x4911102: xdr_reference (in /lib/libc-2.5.so)
==4142==    by 0x491105F: xdr_pointer (in /lib/libc-2.5.so)
==4142==    by 0x109D05: ??? (in /usr/sbin/showmount)
==4142==    by 0x109E7E: ??? (in /usr/sbin/showmount)
==4142==    by 0x49110A7: xdr_reference (in /lib/libc-2.5.so)
==4142==    by 0x491105F: xdr_pointer (in /lib/libc-2.5.so)
==4142==    by 0x109CB5: xdr_exports (in /usr/sbin/showmount)	//clnt_call调用的xdr_exports里面申请的内存
==4142==    by 0x490A596: clnttcp_call (in /lib/libc-2.5.so)
==4142==    by 0x1090CA: main (in /usr/sbin/showmount)
==4142==
==4142== 9 bytes in 1 blocks are indirectly lost in loss record 2 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x490FE61: xdr_string (in /lib/libc-2.5.so)
==4142==    by 0x109E2B: ??? (in /usr/sbin/showmount)
==4142==    by 0x109E5D: ??? (in /usr/sbin/showmount)
==4142==    by 0x49110A7: xdr_reference (in /lib/libc-2.5.so)
==4142==    by 0x491105F: xdr_pointer (in /lib/libc-2.5.so)
==4142==    by 0x109CB5: xdr_exports (in /usr/sbin/showmount)	//clnt_call调用的xdr_exports里面申请的内存
==4142==    by 0x490A596: clnttcp_call (in /lib/libc-2.5.so)
==4142==    by 0x1090CA: main (in /usr/sbin/showmount)
==4142==
==4142== 16 bytes in 1 blocks are still reachable in loss record 3 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x490FE61: xdr_string (in /lib/libc-2.5.so)
==4142==    by 0x109D9B: ??? (in /usr/sbin/showmount)
==4142==    by 0x109DCD: ??? (in /usr/sbin/showmount)
==4142==    by 0x49110A7: xdr_reference (in /lib/libc-2.5.so)
==4142==    by 0x491105F: xdr_pointer (in /lib/libc-2.5.so)
==4142==    by 0x109D05: ??? (in /usr/sbin/showmount)
==4142==    by 0x109E7E: ??? (in /usr/sbin/showmount)
==4142==    by 0x49110A7: xdr_reference (in /lib/libc-2.5.so)
==4142==    by 0x491105F: xdr_pointer (in /lib/libc-2.5.so)
==4142==    by 0x109CB5: xdr_exports (in /usr/sbin/showmount)	//clnt_call调用的xdr_exports里面申请的内存
==4142==    by 0x490A596: clnttcp_call (in /lib/libc-2.5.so)
==4142==
==4142== 29 (12 direct, 17 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 11
==4142==    at 0x4804EC2: calloc (vg_replace_malloc.c:418)
==4142==    by 0x4911102: xdr_reference (in /lib/libc-2.5.so)
==4142==    by 0x491105F: xdr_pointer (in /lib/libc-2.5.so)
==4142==    by 0x109CB5: xdr_exports (in /usr/sbin/showmount)	//clnt_call调用的xdr_exports里面申请的内存
==4142==    by 0x490A596: clnttcp_call (in /lib/libc-2.5.so)
==4142==    by 0x1090CA: main (in /usr/sbin/showmount)
==4142==
==4142== 36 bytes in 1 blocks are indirectly lost in loss record 5 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x4908A50: authunix_create (in /lib/libc-2.5.so)
==4142==    by 0x49085FC: authunix_create_default (in /lib/libc-2.5.so)	//authunix_create_default里面申请的内存
==4142==    by 0x109052: main (in /usr/sbin/showmount)
==4142==
==4142== 40 bytes in 1 blocks are indirectly lost in loss record 6 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x4908952: authunix_create (in /lib/libc-2.5.so)
==4142==    by 0x49085FC: authunix_create_default (in /lib/libc-2.5.so)	//authunix_create_default里面申请的内存
==4142==    by 0x109052: main (in /usr/sbin/showmount)
==4142==
==4142== 68 bytes in 1 blocks are indirectly lost in loss record 7 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x4910692: xdrrec_create (in /lib/libc-2.5.so)
==4142==    by 0x490A20C: clnttcp_create (in /lib/libc-2.5.so)	//clnttcp_create里面申请的内存，showmount未执行clntudp_create，这个函数应该也申请了内存
==4142==    by 0x109043: main (in /usr/sbin/showmount)
==4142==
==4142== 100 bytes in 1 blocks are indirectly lost in loss record 8 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x490A051: clnttcp_create (in /lib/libc-2.5.so)	//clnttcp_create里面申请的内存
==4142==    by 0x109043: main (in /usr/sbin/showmount)
==4142==
==4142== 432 bytes in 1 blocks are indirectly lost in loss record 9 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x4908964: authunix_create (in /lib/libc-2.5.so)
==4142==    by 0x49085FC: authunix_create_default (in /lib/libc-2.5.so)	//authunix_create_default里面申请的内存
==4142==    by 0x109052: main (in /usr/sbin/showmount)
==4142==
==4142== 8,004 bytes in 1 blocks are indirectly lost in loss record 10 of 11
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x49106D7: xdrrec_create (in /lib/libc-2.5.so)
==4142==    by 0x490A20C: clnttcp_create (in /lib/libc-2.5.so)	//clnttcp_create里面申请的内存
==4142==    by 0x109043: main (in /usr/sbin/showmount)
==4142==
==4142== 8,692 (12 direct, 8,680 indirect) bytes in 1 blocks are definitely lost
==4142==    at 0x4805B83: malloc (vg_replace_malloc.c:195)
==4142==    by 0x490A042: clnttcp_create (in /lib/libc-2.5.so)	//clnttcp_create里面申请的内存
==4142==    by 0x109043: main (in /usr/sbin/showmount)

问题集中在clnttcp_create（clntudp_create）、authunix_create_default和xdr_exports三个函数，这三个函数分别创建了RPC客户、RPC客户授权信息和NFS服务器的共享目录列表，也就是说这三个函数创建的资源需要在退出前释放。
man clnt×××××和man xdr_××××一系列函数说明后，找到了释放上述资源的函数（代码中//注释的部分）

懒得装nfs-utils编译的依赖，我没有重编译showmount，但是在我提取的代码修改后用valgrind测试没有内存泄漏。
nfs-utils已经升级到1.2.6，showmount里面的代码增加了clnt_destroy，但是没有auth_destroy和xdr_free，centos不能yum到1.2.6的showmount，我再次偷懒没编译，不知道是否依然存在内存泄漏。

测试环境：CentOS5 2.6.18-308.13.1.el5 showmount版本1.0.9 valgrind版本3.5.0

如有错误，欢迎指正吐舌头

fjhjsjy
关注
对目标主机进行“showmount -e“操作，此操作将泄露目标主机大量敏感信息，漏洞修复
weixin_52200604的博客
02-20 1万+
漏洞描述 可以对目标主机进行"showmount -e"操作，此操作将泄露目标主机大量敏感信息，比如目录结构。更糟糕的是，如果访问控制不严的话，攻击者有可能直接访问到目标主机上的数据。 解决方案 NSFOCUS建议您采取以下措施以降低威胁: * 限制可以获取NFS输出列表的IP和用户。 * 除非绝对必要，请关闭NFS服务、MOUNTD。 漏洞分析： 在NFS服务端设置允许挂载客户端的IP并赋予权限后，赋予权限的的IP地址是可以挂载nfs共享目录的，没有赋予权限的IP地址不能挂载nfs共享目录，但是通过sho
烂泥：【解决】NFS服务器使用showmount –e命令报错
weixin_33801856的博客
09-15 2109
本文由秀依林枫提供友情赞助，首发于烂泥行天下。 今天在NFS服务器使用showmount –e查看NFS共享目录时，发现系统一直显示如下错误： clnt_create: RPC: Port mapper failure - Timed out 查询相关资料显示，很有可能是因为NFS服务器的hosts文件中的域名和NFS服务器的IP地址不对应造成的。 查看NFS服务器的hosts文件，如...
Linux客户端 使用showmount -e ＜nfs服务器端ip＞ 报错 clnt create:RPC:Unable to receive
最新发布
m0_73886455的博客
10-24 313
服务器端可以使用showmount -e 展示 共享的目录信息。再次到客户端使用showmount -e命令。在服务器端 确保防火墙允许 NFS 流量。在 RHEL 中，你可以使用。
showmount
真理部
01-02 1770
showmount命令用于查询NFS服务器的相关信息  # showmount --help  Usage: showmount [-adehv]         [--all] [--directories] [--exports]         [--no-headers] [--help] [--version] [host]  -a或--all     以 host:dir
解决目标主机showmount -e信息泄露(CVE-1999-0554)
weixin_64157795的博客
09-30 1196
目前，我有三台主机，分别为主机a，主机b和主机c，其中主机a为服务器，部署了nfs，只允许主机b使用，然而主机c可以通过showmount -e命令来浏览主机a的目录清单。在NFS服务器上的/etc/hosts.allow和/etc/hosts.deny文件添加以下内容即可解决该问题。#主机c也可以使用showmount -e命令查看nfs服务器上共享出来的目录信息。#主机a的nfs服务配置文件，其中10.28.7.210是主机b的IP地址。#主机b使用showmount -e命令可以查看到的信息。
无法访问目标主机怎么解决_Linux漏洞目标主机showmount -e信息泄露（CEE-1999-0554）的解决方法...
weixin_39569543的博客
12-01 2591
上午本来已经码了一遍了，结果莫名其妙的发布不了，也不能保存草稿，只能重新再码一遍，尴尬。。。。。这个问题已经解决了有一段时间了，今天想起来就想整理一下发布出来。大致情况是甲方的服务器在做等保测评检测的时候，被某安全机构扫描出来多个漏洞，其中一个漏洞就是漏洞目标主机showmount -e信息泄露（CEE-1999-0554）刚看到的时候没当回事，结果百度、谷歌了一圈竟然都没有直接的解决方法，只好自...
CrtDumpMemoryLeaks报告程序中的内存泄露问题（简单示例代码）
worldy的专栏
11-02 849
_CrtDumpMemoryLeaks报告程序中的内存泄露问题（简单示例代码） #include "stdafx.h"    #include    #include       #ifdef _DEBUG //这个要加上，否则不会输出定义到那个文件中（及不包含存在内存泄露的该cpp文件的相关信息）       #define new  new(_NORMAL_BLO
_CrtDumpMemoryLeaks()检查是否存在内存泄漏
gy笨瓜的博客
02-03 2220
以下仅为直观感受，如需详细理解，需查阅官方文档。 测试环境: Windows系统 + Visual Studio _CrtDumpMemoryLeaks()可以用于检查程序中是否存在内存泄漏，即：        使用new或者malloc等操作符在堆上分配内存后，如果在调用_CrtDumpMemoryLeaks()函数之前未进行释放，则会在VS的输出窗口输出相关提示。 【sample】 int main(int argc, char **
内存泄漏
程序员小明
10-06 325
一、什么是内存泄漏 由于内存管理失败导致堆内存忘记释放或者无法释放，导致堆内存无法循环使用的情况叫做内存泄漏 注意：当程序结束后所有的资源都会被系统回收，包括泄漏的内存 二、内存泄漏的原因 1、C语言中malloc/free函数不匹配(忘记写free或者没有执行到free)，在C++中类的构造函数和析构函数中没有匹配的调用new和delete函数 2、 在释放对象数组时在delete中没有使用方括...
关于如何解决目标主机showmount -e信息泄露（CVE-1999-0554）的问题
weixin_55821558的博客
08-24 4162
我现在手上有三台主机，分别为主机host1，主机host2，主机host3，其中主机host1为服务其，并且部署了NFS，而且只允许主机host2使用，然而呢，主机host3可以通过showmount -e命令来浏览主机host1的目录清单。在NFS服务器上的/etc/hosts.allow和/etc/hosts.deny文件添加以下内容即可解决该问题。在我们的日常工作中，企业和单位一般都会使用NFS网络文件系统，最近在工作中，遇到了"编辑/etc/hosts.deny文件。"的问题，并最终做出如下处置。
目标主机showmount -e信息泄露(CVE-1999-0554)修复方案
热门推荐
weixin_46516542的博客
04-19 1万+
1. 首先查看你的nfs配置 cat /etc/exports 然后你在同网段能与这台机子通信的其他机器上执行showmount -eXXXX（nfs服务端ip） 问题：当同网段其他服务器执行 showmount -e XXXX（ip）时，同样会看到共享信息 影响：NFS服务配置漏洞赋予了根目录远程可写权限，导致/root/.ssh/authorized_keys可被修改，实现远程ssh无密码登录。 4、Centos6的NFS服务叫做rpcbind，而Centos5的NFS服务叫por..
showmount -e漏洞修复，实测已完成修复
weixin_46062349的博客
09-26 1559
nfs漏洞之showmount -e漏洞修复
目标主机showmount -e信息泄露(nfs漏洞)
y_zilong的博客
12-23 5578
可以对目标主机进行"showmount -e"操作，此操作将泄露目标主机大量敏感信息，比如目录结构。更糟糕的是，如果访问控制不严的话，攻击者有可能直接访问到目标主机上的数据。 NSFOCUS建议您采取以下措施以降低威胁: * 限制可以获取NFS输出列表的IP和用户。 * 除非绝对必要，请关闭NFS服务、MOUNTD。 解决：vi /etc/hosts.deny 编辑这个配置文件在里面加上：mountd: all 就可以 /etc/hosts.deny mountd: all ...
二十八种未授权访问漏洞合集（暂时最全）
墨痕诉清风的博客
01-04 5000
目录 0x01 未授权漏洞预览 0x02 Active MQ 未授权访问 0x03 Atlassian Crowd 未授权访问 0x04 CouchDB 未授权访问 0x05 Docker 未授权访问 0x06 Dubbo 未授权访问 0x07 Druid 未授权访问 0x08 Elasticsearch 未授权访问 0x09 FTP 未授权访问 0x10 HadoopYARN 未授权访问 0x11 JBoss 未授权访问 0x12 Jenkins 未授权访问 0x13 Jupyt
目标主机showmount -e信息泄露(CVE-1999-0554)，如何禁止只允许特定主机使用showmount -e查看挂载列表
wangbaosongmsn的博客
12-02 1854
最近单位信息系统做安全等保，因为服务器使用了nfs文件共享，而导致在等保扫描中发现了一个高危漏洞，通过showmount -e可以展示nfs挂载列表，然后建议整改方法是限制使用showmount -e展示列表的主机，也就是说在使用nfs的客户端可以通过showmount -e展示可挂载的主机列表，其他主机均不可以使用showmount -e展示可挂载列表。思考了一番，发觉还是在nfs服务器端用iptables防火墙来限制好，那么现在遇到了几个问题： 1 客户端nfs使用mount或者showmount命令
目标主机showmount -e信息泄露(CVE-1999-0554)
h1040753780的博客
09-15 1113
详细描述: 可以对目标主机进行"showmount -e"操作，此操作将泄露目标主机大量敏感信息，比如目录结构。更糟糕的是，如果访问控制不严的话，攻击者有可能直接访问到目标主机上的数据 解决方法: NSFOCUS建议您采取以下措施以降低威胁 解决方式： * 限制可以获取NFS输出列表的IP和用户。 * 除非绝对必要，请关闭NFS服务、MOUNTD。 具体操作： #在NFS服务器上： vim /etc/hosts.allow mountd:192.168.24.68 rpcbind: 192.1
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值