Re: Attention Windows Users

"Skywise" <into@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:11rdtfgjc2hnb26@xxxxxxxxxxxxxxxxxxxxx
> [...]
> It was agreed that it is a "design limitation" of C that allows buffer
> overflows and that a programmer must take specific steps to avoid and
> test for possible problems.

Well, those comments were all from people who have only a rudimentary
knowledge of buffer overrun exploits then.

As I mentioned before, a variable stored on the stack provides the most
convenient way to exploit a buffer overrun. After all, it gives you a
direct path to a return address that can be overwritten, for the purpose of
executing code.

But exploits are NOT limited to use of buffers on the stack. With the
existing OS architectures, a buffer overrun *anywhere* has the potential to
allow an attacker to execute hostile code. Different situations present
different challenges to the attacker, but the potential always exists
regardless.

Assuming XBasic does bounds checking on all memory access, it should still
be immune to buffer overrun errors. But the way it allocates storage is
irrelevant to that question. And if it *doesn't* do bounds checking on all
memory access, then it too is susceptible to buffer overrun errors.

Frankly, the issue is unlikely to be a significant concern in the case of
XBasic. There are at least two things that need to hold for an attacker to
be interested in finding a vulnerability: popularity, and opportunity.
Popularity, because successfully exploiting software that only a handful of
people use doesn't accomplish much. Opportunity, in the sense that the
targeted software needs to be in a position to accept anonymous input
(usually from over the Internet somehow, whether directly or indirectly).

I would guess that XBasic programs fail both of these criteria.

> I'd also like to mention that the name "XBasic" really means "ex-basic".
> The language at first glance appears like a basic but it's not a true
> basic langauge. For one thing, it's not run-time interpreted but rather
> compiles to assembly. It's fast. It's not a 'toy' language.

There are plenty of version of BASIC that are compiled. The most popular
incarnations have been interpreted, of course, but nothing about the
language requires that.

As far as "toy" language goes, I guess that's in the eye of the beholder.
IMHO, being interpreted versus compiled is irrelevant to the question of
"toy". More important, in my opinion, are things like type strictness,
structured flow, and the like. Just as there are plenty of compiled BASICs,
there are plenty of BASICs that include advanced features. I'll take your
word for it that XBasic is one of them. :)

Pete


.

Relevant Pages

  • Re: How to find username who has accessed my file
    ... Here you're doing experimentation but probably not reading ... have basics. ... You asked for some kernel API converting int into string. ... You call some buffer, a 'string', because bytes in that ...
    (comp.os.linux.development.system)
  • DirectSound buffer management
    ... The basics seems quite, well, ... the latter means every sound has an 'extra' copy taking up memory. ... When you want to play a sound, you create a DIRECTSOUNDBUFFER of the right ... before playing this buffer. ...
    (microsoft.public.win32.programmer.directx.audio)
  • Re: Buffing/Polishing Howto?
    ... You'll find some good info on buffing here: ... > Anyone got any pointers on the basics of polishing metal with a buffer like ...
    (rec.crafts.metalworking)
  • Re: Helpful Practical Uses of Conditional Assembly
    ... it would be interessting if you could explain to me what buffer ... sees this lack of "buffer overrun" detection...s/he then simply formulates ... Microsoft Windows (also, Microsoft Word, Microsoft Excel, ... Microsoft have been coding Windows for decades and clearly have absolute ...
    (alt.lang.asm)
  • Re: Public disclosure of discovered vulnerabilities
    ... > David Brown wrote: ... buffer overruns. ... Avoiding buffer overrun is ... > That's not merely saying there's no general correctness prover, ...
    (sci.crypt)
Loading