Re: Possible format string vulnerability
Philip Tellis <[email protected]> Sat, 22 Aug 2015 17:09:54 -0400
| Newsgroups | gmane.network.instant-messaging.ayttm.user |
|---|---|
| Message-ID | <CAJ4Gv_aDbnWjHDZhyo6qcfTXntF993k5yEMoZabr8sbV87O6zQ@mail.gmail.com> |
--===============3806027988964683996== Content-Type: multipart/alternative; boundary=089e0160b87a598e84051decce37 --089e0160b87a598e84051decce37 Content-Type: text/plain; charset=UTF-8 I'll look into it... Might also move to github. Makes contributions much easier. On 22 Aug 2015 4:51 pm, "Kaleb" <[email protected]> wrote: > > Considering the last commit was dated 2011-12-15 03:07:28, I doubt anything will be changed. > > It would be cool if somebody were to pick this back up, but I don't see it happening. > > On Sat, Aug 22, 2015 at 4:24 PM, Kapil Anand <[email protected]> wrote: >> >> Hi, >> >> I work in information flow analysis of programs and my analysis gave a possible warning with respect to format string vulnerability in ayttm. I had pointed out this behaviour earlier, so wanted to check whether code base has been modified to fix this vulnerability. >> >> Function "http_connect" populates "debug_buff" through "inputline". "inputline" is populated through an external "recv" command. "debugf" is passed directly to printf without a format string. >> >> >> Code: (in http_connect) >> >> //Populates inputine through recv call >> ay_recv_line(sockfd,&inputline) >> >> //Moves inputline to debug_buff >> snprintf(debug_buff, sizeof(debug_buff), <%s\n",inputline); >> >> >> //Passes to debug_print a.k.a printf >> debug_print(debug_buff) >> >> Our analysis flagged this behavior. >> >> However, we are not sure whether ayttm developers are aware of this behaviour. This might very well be a false positive. We just wanted to confirm our analysis. >> >> Any response in this regard will be appreciated. >> >> Thanks >> >> Regards, >> Kapil >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Ayttm-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/ayttm-users >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ayttm-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ayttm-users > --089e0160b87a598e84051decce37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">I'll look into it... Might also move to github. Makes co= ntributions much easier. <br></p> <p dir=3D"ltr">On 22 Aug 2015 4:51 pm, "Kaleb" <<a href=3D"mai= lto:[email protected]">[email protected]</a>> wrote:<br> ><br> > Considering the last commit was dated=C2=A02011-12-15 03:07:28, I doub= t anything will be changed.<br> ><br> > It would be cool if somebody were to pick this back up, but I don'= t see it happening.<br> ><br> > On Sat, Aug 22, 2015 at 4:24 PM, Kapil Anand <<a href=3D"mailto:kap= [email protected]">[email protected]</a>> wrote:<br> >><br> >> Hi,<br> >><br> >> I work in information flow analysis of programs and my analysis ga= ve a possible warning with respect to format string vulnerability in=C2=A0a= yttm. I had pointed out this behaviour earlier, so wanted to check whether = code base has been modified to fix this vulnerability.<br> >><br> >> Function "http_connect" populates "debug_buff"= through "inputline". "inputline" is populated through = an external "recv" command. "debugf" is passed directly= to printf without a format string.<br> >><br> >><br> >> Code: (in http_connect)<br> >><br> >> //Populates inputine through recv call<br> >> ay_recv_line(sockfd,&inputline)<br> >><br> >> //Moves inputline to debug_buff<br> >> snprintf(debug_buff, sizeof(debug_buff), <%s\n",inputline)= ;=C2=A0<br> >> =C2=A0=C2=A0<br> >><br> >> //Passes to debug_print a.k.a printf<br> >> debug_print(debug_buff)<br> >><br> >> Our analysis flagged this behavior.=C2=A0<br> >><br> >> However, we are not sure whether=C2=A0ayttm=C2=A0developers are aw= are of this behaviour. This might very well be a false positive. We just wa= nted to confirm our analysis.<br> >><br> >> Any response in this regard will be appreciated.<br> >><br> >> Thanks<br> >><br> >> Regards,<br> >> Kapil<br> >><br> >> ------------------------------------------------------------------= ------------<br> >><br> >> _______________________________________________<br> >> Ayttm-users mailing list<br> >><a href=3D"mailto:[email protected]"> Ayttm-users@l= ists.sourceforge.net</a><br> >><a href=3D"https://lists.sourceforge.net/lists/listinfo/ayttm-users= "> https://lists.sourceforge.net/lists/listinfo/ayttm-users</a><br> >><br> ><br> ><br> > ----------------------------------------------------------------------= --------<br> ><br> > _______________________________________________<br> > Ayttm-users mailing list<br> ><a href=3D"mailto:[email protected]"> Ayttm-users@lists= .sourceforge.net</a><br> ><a href=3D"https://lists.sourceforge.net/lists/listinfo/ayttm-users"> h= ttps://lists.sourceforge.net/lists/listinfo/ayttm-users</a><br> ><br> </p> --089e0160b87a598e84051decce37-- --===============3806027988964683996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ --===============3806027988964683996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ayttm-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ayttm-users --===============3806027988964683996==--