1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

@BPOKE bounds problem?

Discussion in 'Support' started by dcantor, Jun 20, 2009.

  1. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    In testing @BPOKE and @BPEEK to construct 32-bit integers like I described in another thread (it works, by the way), I mistyped and entered this:

    C:\work> set bh=%@balloc[8]
    C:\work> echo %@bpoke[%bh,8,1,0xfe]
    0

    The offset is out of bounds. No error condition was indicated.

    Rex, it would be good if an out-of-bounds offset were flagged with a status code and ignored (i.e., not executed). Without a nonzero status code, it would still be okay if the deposited value (0xfe in this case) were NOT deposited anywhere.

    Is this safe? Does it corrupt some part of process memory? (Of course I wouldn't do it on purpose -- but the offset could be a computed value and could go out of range.)
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    dcantor wrote:

    It already does -- but the @BPOKE can only check if the memory address
    is writable, not whether it is in the range of a previously defined
    @BALLOC. (That would require a LOT more code to track every @BALLOC
    invoked.)


    In this case, it was safe (albeit useless), because it was in the range
    of the extra bytes provided by Windows when it padded the allocation.

    Rex Conn
    JP Software
     
  3. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    So, in general, it could cause a problem if an inadvertent out-of-range @BPOKE clobbered something not in the padding that Windows supplies, if the offset parameter were large enough. Right?

    (I'm not looking for a way to use out-of-range arguments; I'm looking for the likely effect of unintentional bugs.)
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    ----- Original Message -----
    From: "rconn" <>
    To: <ESFabian@comcast.net>
    Sent: Sunday, June 21, 2009 22.55
    Subject: RE: [Support-t-1203] @BPOKE bounds problem?




    function is a character-string representation of an actual memory address
    (in hexadecimal). This certainly makes sense in light of your statement that
    there is no internal table of addresses from @BALLOC calls. V11 should use a
    string which also includes a representation of the upper limit of the area,
    e.g., in the form LOWADDRESS_HIGHADDRESS, or as LOWADDRESS_SIZE. This
    change, transparent to users, would allow safety checking all buffer
    accesses with just a few lines of code.

    An even safer approach would be to actually maintain a table of active
    "buffer descriptor"-s, modeled after file descriptors, so the handle
    returned from @BALLOC would just be an index into the table (as are file
    handles returned by @FILEOPEN, though that table might be maintained by the
    OS or the RTL). This would ensure that a user could not acess an area not
    owned by the process.
    --
    Steve
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    dcantor wrote:


    It would never cause a problem; it will either work if it's within the
    (padded) memory buffer, or it will return an error if it's outside the
    buffer.

    Rex Conn
    JP Software
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    rconn wrote:
    | It would never cause a problem; it will either work if it's within
    | the (padded) memory buffer, or it will return an error if it's
    | outside the buffer.

    Do you mean that each binary buffer resides in a memory block with its own
    access control? What happens if a mangled buffer handle is passed to one of
    the buffer access functions?
    --
    Steve
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    Steve Fábián wrote:

    What I said; it will return an error if it's not writable memory.

    Rex Conn
    JP Software
     
  8. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3

    Thanks for the clarification, Rex. That's the answer that I was looking for.
     
  9. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    rconn wrote:
    | What I said; it will return an error if it's not writable memory.

    Does this mean that if by mistake the handle passed to BPOKE or BWRITE is in
    the area where environment variables, or aliases, or functions are stored,
    those might get mangled? Or does "writable memory" in this instance refer
    only to the set of all buffer areas obtained by @BALLOC calls?

    In either event, my request for V11 security enhancement of binary buffers
    so that each handle would specify both location and size, whether directly
    or indirectly, still remains active.
    --
    Steve
     
  10. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    Steve Fábián wrote:

    Writable memory is anything that TCC has allocated.

    You cannot EVER affect environment variables.

    You might mangle your aliases or functions, provided they're local and
    not global.

    If you spend a few weeks trying to @BPOKE random addresses, you might
    manage to bend or break the command processor. But I consider this
    roughly equivalent to a user asking "If I forget the name of the file I
    want to delete, so I make up a few million other names and delete those
    in the hope that one name will be the one I want, could that cause a
    problem?"

    The @BPOKE syntax assumes that the user isn't a *complete* dufus. It
    will protect you from inadvertent mistakes but not determined
    self-immolation. See also "del /s/x/z \*".

    Rex Conn
    JP Software
     
  11. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    rconn wrote:
    | Steve Fábián wrote:
    || rconn wrote:
    ||| What I said; it will return an error if it's not writable memory.
    ||
    || Does this mean that if by mistake the handle passed to BPOKE or
    || BWRITE is in the area where environment variables, or aliases, or
    || functions are stored, those might get mangled? Or does "writable
    || memory" in this instance refer only to the set of all buffer areas
    || obtained by @BALLOC calls?
    | Writable memory is anything that TCC has allocated.
    |
    | You cannot EVER affect environment variables.
    |
    | You might mangle your aliases or functions, provided they're local
    | and not global.
    |
    | If you spend a few weeks trying to @BPOKE random addresses, you might
    | manage to bend or break the command processor.

    Thanks for the information, it tells us what might be damaged while
    debugging code which write into binary buffers.

    | But I consider this
    | roughly equivalent to a user asking "If I forget the name of the
    | file I want to delete, so I make up a few million other names and
    | delete those in the hope that one name will be the one I want, could
    | that cause a problem?"
    |
    | The @BPOKE syntax assumes that the user isn't a *complete* dufus. It
    | will protect you from inadvertent mistakes but not determined
    | self-immolation. See also "del /s/x/z \*".

    Unfortunately during debugging a simple mistype, such as using the wrong one
    of several buffers, might cause damage. Your answer above describes the
    limits of such damage, which is acceptable.
    --
    Steve
     

Share This Page