[rsyslog] imfile buffer overflow master-candidate
I've found a buffer overflow in imfile in the master-candidate branch. To reproduce, make an imfile config that uses a relative path rather than absolute to a file: ``` module(load="imfile" PollingInterval="10") input( type="imfile" tag="crash" File="crashme" ) *.* /var/log/syslog ``` This results in: ``` 3146.392981790:main thread: deletestateonfiledelete: (unset) 3146.392987727:main thread: addmetadata: (unset) 3146.392993638:main thread: addceetag: (unset) 3146.392999527:main thread: statefile: (unset) *** buffer overflow detected ***: rsyslogd terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] rsyslogd(inputProcessCnf+0x99)[0x4147a9] rsyslogd(cnfDoObj+0x90)[0x414ba0] rsyslogd(yyparse+0xbae)[0x45435e] rsyslogd(load+0xc35)[0x414145] rsyslogd(initAll+0x5ef)[0x448e2f] rsyslogd(main+0x30)[0x40dfe0] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] rsyslogd[0x40e35a] ``` I don't have time to dig into it today but wanted to go ahead and report it. If I correctly use an absolute path to the file (I used a relative by mistake when testing and found this), things work as expected. If I get some time tomorrow to dig into it I will! Cheers, Brian ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] imfile buffer overflow master-candidate
A little more info: Program received signal SIGABRT, Aborted. 0x769efcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) backtrace #0 0x769efcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x769f30d8 in __GI_abort () at abort.c:89 #2 0x76a2c394 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x76b3852b "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x76ac3c9c in __GI___fortify_fail (msg=, msg@entry=0x76b384c2 "buffer overflow detected") at fortify_fail.c:37 #4 0x76ac2b60 in __GI___chk_fail () at chk_fail.c:28 #5 0x763a02cd in memcpy (__len=18446744073709551615, __src=, __dest=0x7fffd040) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #6 checkInstance (inst=0x6b0210) at imfile.c:727 #7 0x763a054d in newInpInst (lst=) at imfile.c:1066 #8 0x004147a9 in inputProcessCnf (o=o@entry=0x6adc60) at rsconf.c:354 #9 0x00414ba0 in cnfDoObj (o=0x6adc60) at rsconf.c:427 #10 0x0045435e in yyparse () at grammar.y:129 #11 0x00414145 in load (cnf=0x695cd0 , confFile=0x470309 "/etc/rsyslog.conf") at rsconf.c:1286 #12 0x00448e2f in initAll (argc=argc@entry=1, argv=argv@entry=0x7fffe688) at rsyslogd.c:1252 #13 0x0040dfe0 in main (argc=1, argv=0x7fffe688) at rsyslogd.c:1640 (gdb) frame 13 #13 0x0040dfe0 in main (argc=1, argv=0x7fffe688) at rsyslogd.c:1640 1640initAll(argc, argv); (gdb) print argc $1 = 1 (gdb) print argv $2 = (char **) 0x7fffe688 On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox wrote: > I've found a buffer overflow in imfile in the master-candidate branch. To > reproduce, make an imfile config that uses a relative path rather than > absolute to a file: > > ``` > module(load="imfile" PollingInterval="10") > > input( > type="imfile" > tag="crash" > File="crashme" > ) > > *.* /var/log/syslog > ``` > > This results in: > > ``` > 3146.392981790:main thread: deletestateonfiledelete: (unset) > 3146.392987727:main thread: addmetadata: (unset) > 3146.392993638:main thread: addceetag: (unset) > 3146.392999527:main thread: statefile: (unset) > *** buffer overflow detected ***: rsyslogd terminated > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] > /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] > /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] > /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] > rsyslogd(inputProcessCnf+0x99)[0x4147a9] > rsyslogd(cnfDoObj+0x90)[0x414ba0] > rsyslogd(yyparse+0xbae)[0x45435e] > rsyslogd(load+0xc35)[0x414145] > rsyslogd(initAll+0x5ef)[0x448e2f] > rsyslogd(main+0x30)[0x40dfe0] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] > rsyslogd[0x40e35a] > ``` > > I don't have time to dig into it today but wanted to go ahead and report > it. If I correctly use an absolute path to the file (I used a relative by > mistake when testing and found this), things work as expected. > > If I get some time tomorrow to dig into it I will! > > Cheers, > Brian > > ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] imfile buffer overflow master-candidate
line 727 in imfile.c : memcpy(dirn, inst->pszFileName, i); /* do not copy slash */ On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox wrote: > I've found a buffer overflow in imfile in the master-candidate branch. To > reproduce, make an imfile config that uses a relative path rather than > absolute to a file: > > ``` > module(load="imfile" PollingInterval="10") > > input( > type="imfile" > tag="crash" > File="crashme" > ) > > *.* /var/log/syslog > ``` > > This results in: > > ``` > 3146.392981790:main thread: deletestateonfiledelete: (unset) > 3146.392987727:main thread: addmetadata: (unset) > 3146.392993638:main thread: addceetag: (unset) > 3146.392999527:main thread: statefile: (unset) > *** buffer overflow detected ***: rsyslogd terminated > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] > /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] > /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] > /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] > rsyslogd(inputProcessCnf+0x99)[0x4147a9] > rsyslogd(cnfDoObj+0x90)[0x414ba0] > rsyslogd(yyparse+0xbae)[0x45435e] > rsyslogd(load+0xc35)[0x414145] > rsyslogd(initAll+0x5ef)[0x448e2f] > rsyslogd(main+0x30)[0x40dfe0] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] > rsyslogd[0x40e35a] > ``` > > I don't have time to dig into it today but wanted to go ahead and report > it. If I correctly use an absolute path to the file (I used a relative by > mistake when testing and found this), things work as expected. > > If I get some time tomorrow to dig into it I will! > > Cheers, > Brian > > ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] imfile buffer overflow master-candidate
https://github.com/rsyslog/rsyslog/blob/b5649a98107a8e6b7042e103f17bb16e907504f2/plugins/imfile/imfile.c#L686 Looks like getBasename should perhaps return a -1 if it doesn't find a slash - and then we can "do the right thing" based on that. I'll see if I can sneak in time for a fix today or tomorrow. Cheers, Brian On Thu, Mar 3, 2016 at 9:04 AM, Brian Knox wrote: > line 727 in imfile.c : > > memcpy(dirn, inst->pszFileName, i); /* do not copy slash */ > > > On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox wrote: > >> I've found a buffer overflow in imfile in the master-candidate branch. >> To reproduce, make an imfile config that uses a relative path rather than >> absolute to a file: >> >> ``` >> module(load="imfile" PollingInterval="10") >> >> input( >> type="imfile" >> tag="crash" >> File="crashme" >> ) >> >> *.* /var/log/syslog >> ``` >> >> This results in: >> >> ``` >> 3146.392981790:main thread: deletestateonfiledelete: (unset) >> 3146.392987727:main thread: addmetadata: (unset) >> 3146.392993638:main thread: addceetag: (unset) >> 3146.392999527:main thread: statefile: (unset) >> *** buffer overflow detected ***: rsyslogd terminated >> === Backtrace: = >> /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] >> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] >> /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] >> /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] >> /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] >> rsyslogd(inputProcessCnf+0x99)[0x4147a9] >> rsyslogd(cnfDoObj+0x90)[0x414ba0] >> rsyslogd(yyparse+0xbae)[0x45435e] >> rsyslogd(load+0xc35)[0x414145] >> rsyslogd(initAll+0x5ef)[0x448e2f] >> rsyslogd(main+0x30)[0x40dfe0] >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] >> rsyslogd[0x40e35a] >> ``` >> >> I don't have time to dig into it today but wanted to go ahead and report >> it. If I correctly use an absolute path to the file (I used a relative by >> mistake when testing and found this), things work as expected. >> >> If I get some time tomorrow to dig into it I will! >> >> Cheers, >> Brian >> >> > ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] imfile buffer overflow master-candidate
Here we go - https://github.com/rsyslog/rsyslog/pull/840 On Thu, Mar 3, 2016 at 9:15 AM, Brian Knox wrote: > > https://github.com/rsyslog/rsyslog/blob/b5649a98107a8e6b7042e103f17bb16e907504f2/plugins/imfile/imfile.c#L686 > > Looks like getBasename should perhaps return a -1 if it doesn't find a > slash - and then we can "do the right thing" based on that. I'll see if I > can sneak in time for a fix today or tomorrow. > > Cheers, > Brian > > On Thu, Mar 3, 2016 at 9:04 AM, Brian Knox wrote: > >> line 727 in imfile.c : >> >> memcpy(dirn, inst->pszFileName, i); /* do not copy slash */ >> >> >> On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox >> wrote: >> >>> I've found a buffer overflow in imfile in the master-candidate branch. >>> To reproduce, make an imfile config that uses a relative path rather than >>> absolute to a file: >>> >>> ``` >>> module(load="imfile" PollingInterval="10") >>> >>> input( >>> type="imfile" >>> tag="crash" >>> File="crashme" >>> ) >>> >>> *.* /var/log/syslog >>> ``` >>> >>> This results in: >>> >>> ``` >>> 3146.392981790:main thread: deletestateonfiledelete: (unset) >>> 3146.392987727:main thread: addmetadata: (unset) >>> 3146.392993638:main thread: addceetag: (unset) >>> 3146.392999527:main thread: statefile: (unset) >>> *** buffer overflow detected ***: rsyslogd terminated >>> === Backtrace: = >>> /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] >>> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] >>> /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] >>> /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] >>> /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] >>> rsyslogd(inputProcessCnf+0x99)[0x4147a9] >>> rsyslogd(cnfDoObj+0x90)[0x414ba0] >>> rsyslogd(yyparse+0xbae)[0x45435e] >>> rsyslogd(load+0xc35)[0x414145] >>> rsyslogd(initAll+0x5ef)[0x448e2f] >>> rsyslogd(main+0x30)[0x40dfe0] >>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] >>> rsyslogd[0x40e35a] >>> ``` >>> >>> I don't have time to dig into it today but wanted to go ahead and report >>> it. If I correctly use an absolute path to the file (I used a relative by >>> mistake when testing and found this), things work as expected. >>> >>> If I get some time tomorrow to dig into it I will! >>> >>> Cheers, >>> Brian >>> >>> >> > ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
