@BPOKE bounds problem?

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
May 29, 2008
517
3
Groton, CT
#1
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.)
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#2
dcantor wrote:

> 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.
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.)


> 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.)
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
 
May 29, 2008
517
3
Groton, CT
#3
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
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
----- Original Message -----
From: "rconn" <>
To: <ESFabian@comcast.net>
Sent: Sunday, June 21, 2009 22.55
Subject: RE: [Support-t-1203] @BPOKE bounds problem?



> dcantor wrote:
>
>
> ---Quote---
>> 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.
> ---End Quote---
> 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.)

>From my observation, it seems that the value returned by the @BALLOC
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
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#5
dcantor wrote:


> 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?
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
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
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#7
Steve Fábián wrote:

> 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?
What I said; it will return an error if it's not writable memory.

Rex Conn
JP Software
 
#9
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
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#10
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. 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
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