Re: Buffer Overflows in cmd.cc

--000000000000710a0b05bf480da4
Content-Type: text/plain; charset="UTF-8"

Hi Michael,

Thank you for your bug report. I think you are correctly spotting a problem.
In fact, similar bugs were found in the past. Thank you very much for your
patch too, and for the hint to reproduce the bug. We will review it all in
detail
for a future release fixing the problem.

Regards,
Antonio Ceballos


On Mon, Apr 5, 2021 at 5:54 AM Michael Vaughan (RIT Student) <
[email protected]> wrote:

> Hello,
>
> I wanted to report a potentially exploitable issue within the
> cmd_pgnload() and cmd_pgnreplay() functions in cmd.cc. In the loop between
> lines 482-485 in the former function, a specially crafted epdline could
> overrun the data buffer located here:
>
> char data[MAXSTR]="";
> char epdline[MAXSTR]="";
>
> /* snip */
>
> int i=0;
>
>
> *while ( epdline[i] != '\n' ) {  data[i+9] = epdline[i];  ++i;*
> *}*
>
> Since this loop only ends when there is a newline within epdline, the end
> of the data buffer is not checked and the program will continue to copy
> bytes into and past the buffer, eventually overwriting the return address
> on the stack. A PGN file that exploits this bug is potentially possible,
> but it is easier to reproduce this in gdb by setting a breakpoint on the
> load_pgn_as_epd() function. Then load any compliant file with the pgnload
> command as follows:
>
> pgnload *<filename>*
>
> If you step after the SaveEPD() call but before the temporary file
> ".tmp.epd" is opened with fopen(), you can write to (or replace) the
> temporary file with a buffer overflow payload, like two hundred of "A".
> Continuing the program will cause it to open and copy this into the 128
> byte data buffer, overflowing it and overwriting the return address, as
> well as any stack cookie or other data in the way. This code is mirrored in
> the cmd_pgnreplay() function also, and can be mitigated in the same way. It
> should be reproducible there using the same steps.
>
> I have attached a patch to this email with a potential fix to this issue.
> I hope this finds you well.
>
> Regards,
>
> Michael Vaughan
>

--000000000000710a0b05bf480da4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Hi =
Michael,</div><div class=3D"gmail_default" style=3D"font-size:small"><br></=
div><div class=3D"gmail_default" style=3D"font-size:small">Thank you for yo=
ur bug report. I think you are correctly spotting a problem.</div><div clas=
s=3D"gmail_default" style=3D"font-size:small">In fact, similar bugs were fo=
und in the past. Thank you very much for your <br></div><div class=3D"gmail=
_default" style=3D"font-size:small">patch too, and for the hint to reproduc=
e the bug. We will review it all in detail <br></div><div class=3D"gmail_de=
fault" style=3D"font-size:small">for a future release fixing the problem.</=
div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div c=
lass=3D"gmail_default" style=3D"font-size:small">Regards,</div><div class=
=3D"gmail_default" style=3D"font-size:small">Antonio Ceballos</div><div cla=
ss=3D"gmail_default" style=3D"font-size:small"><br></div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 5, 202=
1 at 5:54 AM Michael Vaughan (RIT Student) &lt;<a href=3D"mailto:mav8557@ri=
t.edu">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>Hello,</div><div><br></div><div=
>I wanted to report a potentially exploitable issue within the cmd_pgnload(=
) and cmd_pgnreplay() functions in cmd.cc. In the loop between lines 482-48=
5 in the former function, a specially crafted epdline could overrun the dat=
a buffer located here:</div><div><br></div><div>char data[MAXSTR]=3D&quot;&=
quot;;<br>char epdline[MAXSTR]=3D&quot;&quot;;</div><div><br></div><div>/* =
snip */</div><div><br></div><div>int i=3D0;<br><b>while ( epdline[i] !=3D &=
#39;\n&#39; ) {<br>=C2=A0 data[i+9] =3D epdline[i];<br>=C2=A0 ++i;</b></div=
><div><b>}</b></div><div><b><br></b></div><div>Since this loop only ends wh=
en there is a newline within epdline, the end of the data buffer is not che=
cked and the program will continue to copy bytes into and past the buffer, =
eventually overwriting the return address on the stack. A PGN file that exp=
loits this bug is potentially possible, but it is easier to reproduce this =
in gdb by setting a breakpoint on the load_pgn_as_epd() function. Then load=
 any compliant file with the pgnload command as follows:</div><div><br></di=
v><div>pgnload <i>&lt;filename&gt;</i></div><div><br></div><div>If you step=
 after the SaveEPD() call but before the temporary file &quot;.tmp.epd&quot=
; is opened with fopen(), you can write to (or replace) the temporary file =
with a buffer overflow payload, like two hundred of &quot;A&quot;. Continui=
ng the program will cause it to open and copy this into the 128 byte data b=
uffer, overflowing it and overwriting the return address, as well as any st=
ack cookie or other data in the way. This code is mirrored in the cmd_pgnre=
play() function also, and can be mitigated in the same way. It should be re=
producible there using the same steps.<br></div><div><br></div><div>I have =
attached a patch to this email with a potential fix to this issue. I hope t=
his finds you well.</div><div><br></div><div>Regards,</div><div><br></div><=
div>Michael Vaughan<br></div><div><b></b></div></div>
</blockquote></div>

--000000000000710a0b05bf480da4--