@BPOKE bounds problem?

May 29, 2008
567
4
Groton, CT
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
12,340
149
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
567
4
Groton, CT
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.)
 
May 20, 2008
3,515
4
Elkridge, MD, USA
----- 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
12,340
149
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
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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
12,340
149
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
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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
12,340
149
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
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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
 
Similar threads
Thread starter Title Forum Replies Date
J Problem with bpoke Support 0
Dick Johnson Weird Color Problem Support 8
fishman@panix.com Problem with 27.15 Support 2
M Problem with VSDevCmd.bat in VS 16.7.3 Support 0
R Problem with @INT[ value] in V26 Support 9
M Selecting test "off by one" problem in Take command Support 4
Alpengreis UTF-8 problem in TCC related to Python Support 7
K_Meinhard Small problem in german IDE 26 Support 3
B Problem with color in nested shells Support 1
Joe Caverly Problem creating and switching to a DESKTOP Support 9
vefatica Another popup problem Support 10
Alpengreis ffind dialog (/W) problem Support 4
Alpengreis [TCMD v25.00.24] Small space problem with the DE translation in Prefs-GUI Support 1
Alpengreis [TCMD v25.00.24] Problem with copy and paste and the # char via mouse in TCC Support 6
A Problem with functions @int @decimal and identifying Powershell as a shell. Support 12
B IF command problem in tcexit.btm Support 9
fishman@panix.com Problem at Startup of TCC Support 3
P Problem with SFTP copies Support 7
P Problem with FTP copies Support 10
Jay Sage Problem with Context Menu Copy+Paste+Run Key Assignment Support 7
R Problem with %_do_loop in nested do loops Support 2
fishman@panix.com New Problem with later Windows 10 Support 10
Peter Murschall A little problem with LEAVE and COMMENT Support 5
M Handling of %~I problem Support 4
WinLanEm FOR problem Support 18
K Problem With SCRPUT /u Support 3
vefatica What's TCMD's problem with ^e[0m? Support 13
Peter Murschall IDE: RTL with non-English resources-problem is back in Build 28 Support 4
rps Regex problem: \xnn not recognized as a hex character Support 0
rps PRIORITY LOW problem Support 1
old coot Regex problem: \xnn not recognized as a hex character Support 12
vefatica Another problem with build 22. Support 3
Alpengreis [23.x] Download-Problem Support 2
S Problem with " Support 3
C Problem navigating forums Support 11
x13 Problem listing repository files using DIR http(s)://... Support 8
Joe Caverly Problem with TEE in v22 Support 2
Alpengreis Problem with thousands delimiter and colors Support 17
M Take Command 18, migrating to another machine, license problem. Support 1
B TCC 21.01.50 Problem with ALIAS /r and SET /r Support 2
rps How to? @search problem Support 2
WinLanEm @SELECT problem Support 6
T Fixed Problem with use of Batch parameters in the IDE Support 1
Oz Solomon Problem with "list" Support 14
S V21.24 theme problem Support 2
Alpengreis Problem if command prompt is not legacy Support 4
Alpengreis TCMD.INI: The "super hidden" problem ... Support 6
G Odd problem - screen brightness Support 4
rps V20 In-process pipes problem Support 8
Alpengreis Again theme problem [v20.0.21]? Support 11

Similar threads