What stack exploit ?

[hutch--]

Here is how to solve the problem with any of the masm32 library command line procedures.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

comment * -----------------------------------------------------
                        Build this  template with
                       "CONSOLE ASSEMBLE AND LINK"
        ----------------------------------------------------- *

    .code

start:
   
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    call main

    exit

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

main proc


    .if len(rv(GetCommandLine)) > 128
      print "Warning, Some idiot is trying a stack overflow exploit.",13,10
      ret
    .endif

    cls
    print "Hello World",13,10

    ret

main endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

end start


:cheekygreen:

[Mark Jones]

Hee hee hee! :)  :U

[QvasiModo]

Funny! :bg
Let's just hope no one takes it seriously and believe it's actually a good solution! :bdg

[Ramon Sala]

As Quasimodo says, I expect nobody will take that seriously.

Ramon

[hutch--]

Most buffer overflow exploits involve user inputted data to a buffer that is not controlled in its length so if you set up a CGI on the web or have a very high exposure app then it may be vulnerable to someone feeding it more than the buffer allows. This situation is very simple to fix, limit the length but of course there will be other forms of buffer overflow exploits.

I would be interested to hear solutions to other cases.

[AeroASM]

Funny! :bg
Let's just hope no one takes it seriously and believe it's actually a good solution! :bdg

I don't get it. What is so funny? Why is it not a good solution?

[Mark Jones]

I think QvasiModo meant that the resulting "protection" would be easy to defeat by an experienced cracker?

Personally I find "safeguarding" my executables to be harder than optimizing them. Optimization has its limits - but there's no end to a cracker's infatuation. :(

[QvasiModo]

No, I just don't think that limiting command line handling to 128 bytes is good solution, from a design point of view -- I'd just drop the GetCL function entirely. It does fix the problem, the code posted by Hutch is not exploitable at all (no matter how experienced you are).

Personally I find "safeguarding" my executables to be harder than optimizing them. Optimization has its limits - but there's no end to a cracker's infatuation. :(

So do I :) that's why I prefer string handling functions to enforce text limits (instead of the caller), as well as having those limits configurable (instead of hardcoded into the function).

[hutch--]

Quasimodo,

The GetCL version was written on a win9x box and is dated in 1999 where later OS versions document 32 thousand character command line limits so what I will do when I get the time is produce a table based version for the later OS versions. I could not think of a way to get around checking the command line length but I was interested if anyone else knew of a way to do it as its worth pubishing any tricks like this if it helps.

[QvasiModo]

The GetCL version was written on a win9x box and is dated in 1999...

Ok, now I understand the text size limit.

...where later OS versions document 32 thousand character command line limits so what I will do when I get the time is produce a table based version for the later OS versions. I could not think of a way to get around checking the command line length but I was interested if anyone else knew of a way to do it as its worth pubishing any tricks like this if it helps.

My two cents: how about leaving this one for backwards compatibility, adding the command line length check inside the function (to secure existing apps without having to change their code), and writing a new function? :)

[hutch--]

i am inclined to leave these old ones as they are and do a new one when I get the time. The design I had in mind was one that uses spaces, tabs and commas as delimiters and handles quoted text as well which is a bit more like programming parsing than command line parsing but I think it will work OK.

There are two choices, my preferred one is to grab each argument as the old ones do as it means you can spot arg 1 to the end in one call but there is another option that takes a little more parsing that is no big deal to do which is to rewrite the buffer so that each argument is zero terminated and load the sum total of addresses into an array of pointers. The new comand line limit of 32 thousand characters can be bashed very quickly if it is done right although I doubt that there is a lot of use for this capacity.

[pbrennick]

Hutch,
That is a great idea.  I was just looking at GetCL.asm and it looks like a very well written utility.  Since most of my apps expect a path in the commandline I have the luxury of using PathGetArgs in the shlwapi library.  Did you ever notice that this particular library is just chock full of 'path' stuff?  It might help you in writing your new version.

Anyway, nice utility,
Paul

[Jibz]

Making users perform the check on their own is not a fix, it's a workaround :bg.

The first time I brought up the problem (about a year ago), I posted a simple command line parser which creates the C style argv[] array of pointers to command line arguments. Perhaps some of the ideas could be of use in creating the next version?

Either way, I think it's important to fix the problem at the source no matter how many new similar functions are added to the library. And it would not change the functionality other than apps will no longer crash when given too long a command line :green.

[QvasiModo]

i am inclined to leave these old ones as they are and do a new one when I get the time. The design I had in mind was one that uses spaces, tabs and commas as delimiters and handles quoted text as well which is a bit more like programming parsing than command line parsing but I think it will work OK.

There are two choices, my preferred one is to grab each argument as the old ones do as it means you can spot arg 1 to the end in one call but there is another option that takes a little more parsing that is no big deal to do which is to rewrite the buffer so that each argument is zero terminated and load the sum total of addresses into an array of pointers. The new comand line limit of 32 thousand characters can be bashed very quickly if it is done right although I doubt that there is a lot of use for this capacity.

I have a FASM routine that goes half that way: turns a given ASCIIZ string into an ASCIIZ array (strings one next to the other, ends with a double NULL). Traversing the array forward is fairly trivial, and the code size is small. I also think speed is not important, even with 32k command lines (which are going to be rare anyway). I can post it here if you want to take a look. :)

[hutch--]

Jibz,

What if the user wants a 32 character limit ? use5r defined methods are more flexible, especially when you are dealing with assembler programmers.

QvasiModo,

Thanks for the offer, it will be worth having a look at. I am currently working on the version that grabs a single argument if it exists as I find this type more useful but the other design is also very useful for very long command lines. About the only problem I see is knowing how large to make the array to hold the pointers to each word start on the command line. Probably a user defined limit with the array is the safest way to go as the user should have some idea of the maximum number of arguments that the program will accept.