Question about recognizing buffer overflow exploits in text command files

What techniques can we users use to recognize potential buffer overflow
exploits in text command files?

In a recent thread, a user provides a potentially useful mechanism for
licensing Microsoft Office 2016 Professional Plus.
*Microsoft Office 2016 for free with just a command!*
http://alt.comp.os.windows-10.narkive.com/00SF9G0L/microsoft-office-2016-for-free-with-just-a-command

I only wish to learn from others how to recognize if the command file
supplied in that thread is a potential "buffer overflow exploit".
https://bit.ly/2xu27DU

Looking at that command file, it sure seems to contain a *lot* of
extraneous characters that are entirely unnecessary (e.g., some lines are
literally over 1000 characters long!).

My question is only asking experienced users here how they would go about
confirming whether a buffer overflow exploit (or some other nefarious
exploit) is in that particular command file.

What would _you_ do, to confirm that this command file does Not contain an
exploit (besides the childish response that helps nobody since that's not
the question, which is "don't run it")?

*What technique would you use to confirm or deny the safety of that file?*

--
(Please - no childish responses like "don't run it").

Arlen H. Holder wrote:
What techniques can we users use to recognize potential buffer overflow
exploits in text command files?

In a recent thread, a user provides a potentially useful mechanism for
licensing Microsoft Office 2016 Professional Plus.
*Microsoft Office 2016 for free with just a command!*
http://alt.comp.os.windows-10.narkive.com/00SF9G0L/microsoft-office-2016-for-free-with-just-a-command

I only wish to learn from others how to recognize if the command file
supplied in that thread is a potential "buffer overflow exploit".
https://bit.ly/2xu27DU

Looking at that command file, it sure seems to contain a *lot* of
extraneous characters that are entirely unnecessary (e.g., some lines are
literally over 1000 characters long!).

My question is only asking experienced users here how they would go about
confirming whether a buffer overflow exploit (or some other nefarious
exploit) is in that particular command file.

What would _you_ do, to confirm that this command file does Not contain an
exploit (besides the childish response that helps nobody since that's not
the question, which is "don't run it")?

*What technique would you use to confirm or deny the safety of that file?*


You should try to nail it down a bit closer than that.

http://al.howardknight.net/msgid.cgi...k%404ax.com%3E

998 bytes might be enforced on the server end.
The server could auto-wrap things longer than that,
or the server could reject the article (AIOE has a
filter for line length on body text). Some RFC likely
has the exact number.

There are plenty of "defensive" C routines now for
protection against this.

I'm not quaking in my boots right now. I'm more afraid
of Flash in my browser than this.

Paul

On Sun, 23 Sep 2018 13:33:17 -0400, Paul wrote:

You should try to nail it down a bit closer than that.

Hi Paul,
You got it wrong, but I don't blame you as I know you mean well.

The user who posted that clearly manually *inserted* the backslash line
breaks. It's easy to tell from a simple diff of the three files.

The user who inserted those line breaks for the Usenet post likely did so
*because* the lines were too long, we can presume, for his Usenet nntp
server.

In fact, that user provided a pastebin of the file, which *exactly* meets
the DIFF of the original (while the Usenet post does not).

So you were, unbeknownst to you, fooled by that text paste.

AFAIK, the command file in question is in three places.
1. The original file (lines are clearly longer than 1000 characters)
https://bit.ly/2xu27DU
2. The pastebin (clearly matches exactly the original file #1)
https://pastebin.com/vkGcdjd8
3. The Usenet post (clearly does NOT match the original)
http://al.howardknight.net/msgid.cgi?STYPE=msgid&A=0&MSGI=%3C1f16rd4dqgn3l0hg h3gmtbbe5fvpew18ek%404ax.com%3E

You should use either the original file or the pastebin results.
The Usenet post you referred to does NOT contain the same file!

However, the *only* difference in the Usenet post are the line breaks.
I suspect they were enforced by that users' NNTP server.

Back to the original question ... how can we reliably determine whether
that (original or pastebin) command file contains a known exploit?

On Sun, 23 Sep 2018 16:47:16 -0000 (UTC), "Arlen H. Holder"
wrote:

What techniques can we users use to recognize potential buffer overflow
exploits in text command files?

In a recent thread, a user provides a potentially useful mechanism for
licensing Microsoft Office 2016 Professional Plus.
*Microsoft Office 2016 for free with just a command!*
http://alt.comp.os.windows-10.narkive.com/00SF9G0L/microsoft-office-2016-for-free-with-just-a-command

I only wish to learn from others how to recognize if the command file
supplied in that thread is a potential "buffer overflow exploit".
https://bit.ly/2xu27DU

Looking at that command file, it sure seems to contain a *lot* of
extraneous characters that are entirely unnecessary (e.g., some lines are
literally over 1000 characters long!).

My question is only asking experienced users here how they would go about
confirming whether a buffer overflow exploit (or some other nefarious
exploit) is in that particular command file.

What would _you_ do, to confirm that this command file does Not contain an
exploit (besides the childish response that helps nobody since that's not
the question, which is "don't run it")?

*What technique would you use to confirm or deny the safety of that file?*

Glad you recognized the difference with that script paste in the
usenet post. Good eye, there! That was Goodguy, do not to use that
paste.