If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
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"). |
Ads |
#2
|
|||
|
|||
Question about recognizing buffer overflow exploits in text commandfiles
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 |
#3
|
|||
|
|||
Question about recognizing buffer overflow exploits in text command files
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? |
#4
|
|||
|
|||
Question about recognizing buffer overflow exploits in text command files
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. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|