A small IF platform survey

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

>"ChicagoDave" <david.cornelson@gmail.com> wrote in message
>news:1112376316.309388.127610@z14g2000cwz.googlegroups.com...

>> Of course if your worried about losing 25mb of disk space, I
>> understand. Otherwise it's really not that big of a deal.

I take it you are not on a slow dial-up connection. I'm not either
these days, thankfully, but I was at the time of last year's Comp,
and after downloading the huge competition package, I just didn't want
to spend more pay-per-minute online time to download an even larger
software package just to be able to play one single game.

>> This is really an OS religious issue. There is nothing fundamentally
>> wrong or dangerous in using or installing the .NET Framework. It's no
>> different than the Java runtime. Just a wee (by todays standards) bit
>> bigger.

If you are on dial-up, 10 Mb is a huge difference. Also, I need the
Java runtime for a few things, and I don't need the .Net framework at
all. (And I don't really care about what exactly it is if I don't
need it.)

Now, I'm not one to complain about having to install yet another
interpreter to play a game. But those interpreters usually come at a
reasonable size, and there are more than one or two games for each
of them. I also don't say you shouldn't write your games for .Net or
anything else, just don't expect that as many people will be able or
willing to play them as Z-code or Tads games. (And I think, some of
us do have "non-religious" arguments.)

--
Sophie Frühling

"El arte no viste pantalones."
-- Rubén Darío

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

ChicagoDave wrote:

> Of course if your worried about losing 25mb of disk space, I
> understand. Otherwise it's really not that big of a deal. The same
> people will download x MP3's and not see anything wrong with the disk
> space they use so to me, that's a specious argument.

Most of the IF I play, I play on my PDA, which has a 256mb flash memory card. In that
context, 25mb is a lot. (I *did* put City of Secrets and a glulx terp on there, but even
that is an effort I might not have made if I hadn't paid for it and gotten the pretty
feelies.) Any MP3s and such that I may download, I keep on devices with multiple gb of
hard disk space, so that's not a fair comparison.

Owen

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

"Moreover, while .NET might not be dangerous, playing games that
require it is."

This is fundamentally false. By default, the .NET security settings are
pretty strict. Any unknown application will get rights to execute and
save information to the sandbox area. If there was actually malicious
code in the .NET program (like changing file system things outside of
the sandbox) it would display a managed code security error and refuse
to execute the program. If the program tried to do some sort of piggy
back install, that too would go through the same managed code security
settings and fail.

Now, you can explicitly open up the .NET security client, select a .NET
application, then set it to Full Rights. This would be like downloading
a file to your linux machine, putting it in a publically available
directory, and then giving it root access. You would have to go way out
of your way to allow something like this and if you were only
downloading a game, it would never come up.

I'd also point out that if anyone ever released an IF game with
malware, they would be treated harshly by the community and the word
would spread so fast that a second person would never get hit by the
same dirty tricks.

The .NET framework allows developers to create safe and efficient
programs that _can_ be downloaded without worrying about hurting
someone's machine.

Ask a few of the original downloaders of my Visual Inform program what
they think of what can happen when things go wrong. I accidentally
disabled several systems with my installation program. In .NET, you
couldn't ever do that to someone's PC.

I see that as a good thing.

I agree that Microsoft has a bad track-record. But that's really mostly
related to Outlook, IE, and the older OS's. If you were running Windows
XP SP2 or Windows Server 2003, you'd have about as secure a system as
you can have. The footprint for security holes has been reduced to
almost nothing and in another year, it will diminish further. I think
people with assumptions about MS security from a year or two ago should
re-evaluate those assumptions.

I sympathize with anyone that has to suffer an initial download of the
..NET Framework. If you have an older PC, dial-up connection, or little
free diskspace, then clearly this is a barrier to you running a .NET
based program. But then again, those parameters probably prevent you
from doing a lot of things. Installing the .NET framework just gets
rolled into that list of restrictions.

David C.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

"Icedragon" <icenetREMOVETHIS@icedragon.net> wrote:
>> Moreover, while .NET might not be dangerous, playing games that require
>> it is. One advantage of something like Inform and TADS and Hugo and the
>> like is that it's either very difficult (TADS 2) or effectively
>> impossible (zcode) to write any sort of malware with it.
>
> Then you're trusting the author of TADS, or Frotz, or whatever host you
> choose to not have written any malware into it.

Actually, no trust is required, as the complete source code for both of
those packages is publicly available. You're free to inspect the sources to
your satisfaction, and then install by building from the inspected sources.

> On top of that, it has already been shown that some of these tools
> had/have exploitable buffer overruns in them which would allow you to
> execute anything on that machine.

Really? I don't recall such a case with any of the major IF interpreters.
Reference, please.

--Mike
mjr underscore at hotmail dot com

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

I'll be the first one not to trust Internet Explorer and unknown
ActiveX controls. That's why I have Norton Security lock them down.
Even Internet Explorer has the ability to turn off their execution. You
can set all ActiveX controls to simply not run without any prompting.
You can set them to run after being prompted. Or if you're a fool, you
can set them to run all the time.

But remember, ActiveX controls are 10 year old technology. No one is
suggesting creating anything in ActiveX.

And more to the point. The manner in which an ActiveX control executes
and the manner in which a .NET program or control executes are entirely
two separate architectures. One has no security and one has security
threaded through every aspect of its nature.

David C.

 

[icEDragon]

Archived from groups: rec.games.int-fiction (More info?)

"Mike Roberts" <mjr_@hotmail.com> wrote in message
news:QrC3e.11784$zl.11355@newssvr13.news.prodigy.com...
> "Icedragon" <icenetREMOVETHIS@icedragon.net> wrote:
>>> Moreover, while .NET might not be dangerous, playing games that require
>>> it is. One advantage of something like Inform and TADS and Hugo and the
>>> like is that it's either very difficult (TADS 2) or effectively
>>> impossible (zcode) to write any sort of malware with it.
>>
>> Then you're trusting the author of TADS, or Frotz, or whatever host you
>> choose to not have written any malware into it.
>
> Actually, no trust is required, as the complete source code for both of
> those packages is publicly available. You're free to inspect the sources
> to your satisfaction, and then install by building from the inspected
> sources.
>
>> On top of that, it has already been shown that some of these tools
>> had/have exploitable buffer overruns in them which would allow you to
>> execute anything on that machine.
>
> Really? I don't recall such a case with any of the major IF interpreters.
> Reference, please.

Sure, here is an example. Given that most are written in C++ which prone to
overruns by design, it's more likely there are exploitable overruns than
not. Here is one example from rec.arts.int-fiction of a buffer overrun
(with all respect to David of course). I'm sure if you spend enough time
you'll be able to find one in almost any native-based application, including
Frotz, etc. I would grant that the Z-machine environment certainly lessens
the possibility of finding one.

Newsgroups: rec.arts.int-fiction
From: "David Kinder" <d.kin...@btinternetspamnothankyou.co­m>
Date: Mon, 18 Oct 2004 17:52:56 +0000 (UTC)
Local: Mon, Oct 18 2004 10:52 am
Subject: Re: [inform] minor compiler bug




> when I try to compile this (reduced) piece of code with inform 6.30 the
> compiler crashes. The "error" in my source is due to the missing ";" after
> the function name.


It's a buffer overrun in the compiler. It'll be fixed for the next
version - thanks for reporting it!

David

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, Icedragon <icenetREMOVETHIS@icedragon.net> wrote:
>
> Sure, here is an example. Given that most are written in C++ which prone to
> overruns by design, it's more likely there are exploitable overruns than
> not.
>
> Newsgroups: rec.arts.int-fiction
> From: "David Kinder" <d.kin...@btinternetspamnothankyou.co?m>
> Date: Mon, 18 Oct 2004 17:52:56 +0000 (UTC)
> Local: Mon, Oct 18 2004 10:52 am
> Subject: Re: [inform] minor compiler bug
>
> > It's a buffer overrun in the compiler. It'll be fixed for the next
> > version - thanks for reporting it!

Ah, no, that's a bug in the *compiler*. It would only affect someone
compiling malicious Inform source code. (Which is not a likely or
common case.) It could not affect game-players.

I'm not saying that Z-code interpreters are all well-sandboxed. Some
of them aren't, and I should know because I wrote them. But this
example does not support your contention.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

 

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/2/2005 5:26 PM, Icedragon did proclaim:
> "Mike Roberts" <mjr_@hotmail.com> wrote in message
>>Really? I don't recall such a case with any of the major IF interpreters.
>>Reference, please.
>
> Sure, here is an example. Given that most are written in C++ which prone to
> overruns by design, it's more likely there are exploitable overruns than
> not.

Mike and Zorf have pointed out the error in your example; I'd like to
point out that none of the interpreters for which I've viewed the source
are written in C++. Virtual machines just aren't so complicated to
require an object-oriented design. VMs also tend to check for a lot of
things a bit more carefully than the average program, since an overrun
could clobber things on multiple levels of execution.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

"Icedragon" <icenetREMOVETHIS@icedragon.net> wrote:
>mjr:
>>"Icedragon":
>>> On top of that, it has already been shown that some of these tools
>>> had/have exploitable buffer overruns [...]
>>
>> Really? I don't recall such a case with any of the major IF
>> interpreters. Reference, please.
>
> Sure, here is an example. Given that most are written in C++ which prone
> to overruns by design, it's more likely there are exploitable overruns
> than not. Here is one example from rec.arts.int-fiction of a buffer
> overrun (with all respect to David of course). I'm sure if you spend
> enough time you'll be able to find one in almost any native-based
> application, including Frotz, etc.
>> From: "David Kinder"
>> It's a buffer overrun in the compiler. It'll be fixed for the next
>>version - thanks for reporting it!

That's a compiler, not an interpreter - that's not relevant to your claims.
And even if it were, a buffer overrun bug is not necessarily an
*exploitable* buffer overrun bug, and I see no evidence in the note you cite
that this one's exploitable. So, again, I'm curious what these cases are
where "it has been shown" that there's an exploitable buffer overrun in one
of the popular interpreters.

If all you're saying is "I'm sure exploitable bugs must exist" rather than
"it's been shown" that they exist, well, sure; I wouldn't claim that the
absence of known exploits proves the non-existence of same. But "I'm sure
they must exist" is a rather weaker claim than you first made.

--Mike
mjr underscore at hotmail dot com

 

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/2/2005 7:35 PM, ChicagoDave did proclaim:

> "Moreover, while .NET might not be dangerous, playing games that
> require it is."
>
> This is fundamentally false. By default, the .NET security settings are
> pretty strict. Any unknown application will get rights to execute and
> save information to the sandbox area. If there was actually malicious
> code in the .NET program (like changing file system things outside of
> the sandbox) it would display a managed code security error and refuse
> to execute the program. If the program tried to do some sort of piggy
> back install, that too would go through the same managed code security
> settings and fail.

What about the execution of potentially dangerous scriptable ActiveX
controls? Is an unknown application is allowed to activate controls
marked Safe for Scripting? If so, there's a problem. You can find a
partial list of dangerous controls here:
http://www.oreilly.com/catalog/malmobcode/chapter/ch11.html
Look for the section labeled "Malicious ActiveX Examples" about halfway
down the page.

 

[icEDragon]

Archived from groups: rec.games.int-fiction (More info?)

"Andrew Plotkin" <erkyrath@eblong.com> wrote in message
news:d2nbv1$o6v$1@reader1.panix.com...
> Here, Icedragon <icenetREMOVETHIS@icedragon.net> wrote:
>>
>> Sure, here is an example. Given that most are written in C++ which prone
>> to
>> overruns by design, it's more likely there are exploitable overruns than
>> not.
>>
>> Newsgroups: rec.arts.int-fiction
>> From: "David Kinder" <d.kin...@btinternetspamnothankyou.co?m>
>> Date: Mon, 18 Oct 2004 17:52:56 +0000 (UTC)
>> Local: Mon, Oct 18 2004 10:52 am
>> Subject: Re: [inform] minor compiler bug
>>
>> > It's a buffer overrun in the compiler. It'll be fixed for the next
>> > version - thanks for reporting it!
>
> Ah, no, that's a bug in the *compiler*. It would only affect someone
> compiling malicious Inform source code. (Which is not a likely or
> common case.) It could not affect game-players.

Yes, and it says "compiler" right in the quoted e-mail. I hesitate to
accept anyone claiming any application is 100% secure.

> I'm not saying that Z-code interpreters are all well-sandboxed. Some
> of them aren't, and I should know because I wrote them.

Agreed, and this is the point. Yet some people are saying there is no
Z-code that can overrun them.

> But this
> example does not support your contention.

My original contention: "it has already been shown that some of these tools
had/have exploitable buffer overruns in them"

Compiler == tool. If the tools for the platform have overruns, it's likely
the environments do too.

 

[icEDragon]

Archived from groups: rec.games.int-fiction (More info?)

> I'd like to point out that none of the interpreters for which I've viewed
> the source are written in C++. Virtual machines just aren't so
> complicated to require an object-oriented design. VMs also tend to check
> for a lot of things a bit more carefully than the average program, since
> an overrun could clobber things on multiple levels of execution.

Yes, it's another good reason to use .Net and Java. Neither are prone to
buffer overruns for exactly the reasons you state; all objects on the stack
and heap are fully checked, including bounds and length. They also share
the ability to used sandbox security zones.

A list of interpreters used in IFComp 2004 and their source language:
WinFrotz - C/C++ mix
Frotz - C/C++ mix
Adrift - not open source? (can't verify security, could have same malware)
Hugo - C/C++ mix
ALAN - C++
TADS 2.x - C++

It is clear from this list that C++ is it, and this is what the vast
majority of players are running. Which interpreters are you talking about
that aren't in C++ and used in the competition? Examples?

Let's get back to the original point here though. It was that some people
might hesitate to run .Net or Java code on their machine because it's
somehow less safe or secure. The coup de grace, though is that most users
will run .exe installer programs that come with game packages, any of which
could be set up to execute a task on your machine, or install a back door
for later attacks. At that point, it really doesn't matter which system
you're using.

The nugget is that security should not be the major consideration in
determining the safety of running the games, you are vulnerable in varying
degrees _unless_ all you ever do is load and run .z files in an interpreter
that you code-reviewed and compiled from source yourself. And since you can
sandbox .Net, it is less of a concern than say, native-windows competition
entries or Adrift (assuming it's not open source).

 

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 12:08 AM, ChicagoDave did proclaim:

> I'll be the first one not to trust Internet Explorer and unknown
> ActiveX controls. That's why I have Norton Security lock them down.
> Even Internet Explorer has the ability to turn off their execution. You
> can set all ActiveX controls to simply not run without any prompting.
> You can set them to run after being prompted. Or if you're a fool, you
> can set them to run all the time.
>
> But remember, ActiveX controls are 10 year old technology. No one is
> suggesting creating anything in ActiveX.
>
> And more to the point. The manner in which an ActiveX control executes
> and the manner in which a .NET program or control executes are entirely
> two separate architectures. One has no security and one has security
> threaded through every aspect of its nature.

Well, you avoided directly answering my main question: "Is an unknown
application is allowed to activate controls marked Safe for Scripting?"
I don't use .NET, so I don't know the answer to that. Based on past
experience, I expect that MS hasn't re-implemented their entire
architecture in trusted code, so I further expect that the answer to my
question is 'by default, yes'. The rest of this post will assume that
this is the answer.

I understand that you can set all ActiveX controls to not run without
prompting, but a lot of those controls are used frequently in a lot of
different places; requiring prompting for everything isn't a realistic
option. This is why MS allows different controls to be flagged with
different levels of security, so that some "trusted" controls can be
invoked without prompts. "Safe for scripting" indicates that a control
doesn't do anything malicious. Unfortunately, there are some controls
that are marked as safe, but aren't. There are also controls that
aren't marked as safe, but are signed by a third party and are allowed
to run after prompting. Unfortunately, there are some controls that, as
a "convenience" to the user, will then modify the Windows registry to
indicate that *everything* signed by that third party can be trusted in
the future.

Both of these "features" make me unwilling to use ActiveX for anything,
and leave me nervous about anything that uses ActiveX under the covers.
(And yes, I have stopped using IE and Outlook on my computer in favor
of Firefox and Thunderbird. I also try to avoid using the built-in help
system in favor of Google search.) And that's why I don't have .NET
installed on my PC.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, Icedragon <icenetREMOVETHIS@icedragon.net> wrote:
>
> My original contention: "it has already been shown that some of these tools
> had/have exploitable buffer overruns in them"
>
> Compiler == tool. If the tools for the platform have overruns, it's likely
> the environments do too.

You're just throwing around generalizations now.

The discussion was originally about possible security problems caused
by downloading and playing IF games of various forms.

The risks of IF *development* are a completely different category and,
despite your claim, there are no real implications you can draw from
one to the other. Different code base, different languages, different
tasks.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

 

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 4:37 AM, Icedragon did proclaim:

>>I'd like to point out that none of the interpreters for which I've viewed
>>the source are written in C++. Virtual machines just aren't so
>>complicated to require an object-oriented design. VMs also tend to check
>>for a lot of things a bit more carefully than the average program, since
>>an overrun could clobber things on multiple levels of execution.
>
>
> Yes, it's another good reason to use .Net and Java. Neither are prone to
> buffer overruns for exactly the reasons you state; all objects on the stack
> and heap are fully checked, including bounds and length. They also share
> the ability to used sandbox security zones.

No, it's not a reason to *favor* .NET or Java; the same arguments apply
to all of them, so it is a draw.

> A list of interpreters used in IFComp 2004 and their source language:
> WinFrotz - C/C++ mix
> Frotz - C/C++ mix

Where are you getting your Frotz source? The copy that I have is
written in C, only. I haven't checked, so the headers might make
provision for use by C++, but that doesn't make the code any less pure.
I expect that WinFrotz uses C++ so that it can access the Windows GUI,
but the VM is just plain Frotz and that is pure C and that means that a
program running in the VM won't have access to any C++ insecurities that
hypothetically may exist.

> Adrift - not open source? (can't verify security, could have same malware)
> Hugo - C/C++ mix
> ALAN - C++
> TADS 2.x - C++

The copy of the TADS common VM that I just downloaded appears to be pure
C code. I haven't checked the others, but I'd imagine that the
situation is the same as with WinFrotz; C++ may be used for interfacing
to the GUI on Windows systems, but the VMs themselves are all written in
straight C for reasons of portability.

> It is clear from this list that C++ is it, and this is what the vast
> majority of players are running. Which interpreters are you talking about
> that aren't in C++ and used in the competition? Examples?

It is clear that you don't know what you're talking about.

> Let's get back to the original point here though. It was that some people
> might hesitate to run .Net or Java code on their machine because it's
> somehow less safe or secure. The coup de grace, though is that most users
> will run .exe installer programs that come with game packages, any of which
> could be set up to execute a task on your machine, or install a back door
> for later attacks. At that point, it really doesn't matter which system
> you're using.

Quite true, but I don't see many cross-platform systems that use .exe
installer packages. The formats that I generally see available for
download are base files, or occasionally .zip files containing a
collection of games.

> The nugget is that security should not be the major consideration in
> determining the safety of running the games, you are vulnerable in varying
> degrees _unless_ all you ever do is load and run .z files in an interpreter
> that you code-reviewed and compiled from source yourself.

Actually, I load and run .z files on my Palm PDA.

> And since you can
> sandbox .Net, it is less of a concern than say, native-windows competition
> entries or Adrift (assuming it's not open source).

I don't run native-windows competition entries, period. I don't trust
native code that I find on the Internet, at least until it has sat in my
incoming files folder for a few months without other people reporting
problems. Yes, I'm a bit behind the times, but I don't have any malware
installed, either.

 

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 12:19 PM, Jimmy Maher did proclaim:

> In short: People are not reluctent to download this framework because of
> some hatred of .NET, or Microsoft, or both. They are reluctent because
> they suspect, based on much previous experience, that the game they are
> downloading it for will almost certainly not be worth the effort.

Amen, brother!

 

[icEDragon]

Archived from groups: rec.games.int-fiction (More info?)

>> A list of interpreters used in IFComp 2004 and their source language:
>> WinFrotz - C/C++ mix
>> Frotz - C/C++ mix
>
> Where are you getting your Frotz source? The copy that I have is written
> in C, only. I haven't checked, so the headers might make provision for
> use by C++, but that doesn't make the code any less pure. I expect that
> WinFrotz uses C++ so that it can access the Windows GUI, but the VM is
> just plain Frotz and that is pure C and that means that a program running
> in the VM won't have access to any C++ insecurities that hypothetically
> may exist.

C is even slightly worse. ANSI C is mostly a subset of ANSI C++. The
problems in these languages both come from the use of pointers, strings,
arrays and memory buffers without rules enforcement, and you could almost
see it as a design flaw.

>> Adrift - not open source? (can't verify security, could have same
>> malware)
>> Hugo - C/C++ mix
>> ALAN - C++
>> TADS 2.x - C++
>
> The copy of the TADS common VM that I just downloaded appears to be pure C
> code. I haven't checked the others, but I'd imagine that the situation is
> the same as with WinFrotz; C++ may be used for interfacing to the GUI on
> Windows systems, but the VMs themselves are all written in straight C for
> reasons of portability.
>
>> It is clear from this list that C++ is it, and this is what the vast
>> majority of players are running. Which interpreters are you talking
>> about that aren't in C++ and used in the competition? Examples?
>
> It is clear that you don't know what you're talking about.

It's clear you don't. They are all in C/C++ with the exception of Adrift.
Where are the other interpreters that are non-C++? If you were basing your
logic on the distinction between C and C++, it's erroneous.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

"Icedragon" <icenetREMOVETHIS@icedragon.net> writes:

> A list of interpreters used in IFComp 2004 and their source language:
> WinFrotz - C/C++ mix
> Frotz - C/C++ mix
> Adrift - not open source? (can't verify security, could have same malware)
> Hugo - C/C++ mix
> ALAN - C++
> TADS 2.x - C++

TADS 2, the base Frotz distribution, the base ALAN interpreter, and
the base HUGO interpreter are all written in C, not C++.

> It is clear from this list that C++ is it, and this is what the vast
> majority of players are running.

Here I think you have inadvertently hit upon the big stumbling block
for a single-shot .NET program: most people aren't running it. As it
stands, most everyone will have a z-code interpreter. Many will have a
TADS interpreter and a Hugo interpreter. That gives games written in
those languages a two-fold advantage. One, playing such a game
involves downloading just the game data, not a new interpreter. Your
hypothetical .NET game requires a download of the entire engine, and
quite probably a download of the .NET runtime. This is not a
zero-height barrier. Two, the common language interpreters are used by
a lot of people. So far no nasty bugs or malware have shown up from
them. Your .NET game is an unknown quantity, and could have all kinds
of nasty payloads attached to it.

Stephen

--
Stephen Granade
stephen-usenet@granades.com

 

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 3:15 PM, Icedragon did proclaim:
>>>A list of interpreters used in IFComp 2004 and their source language:
>>>WinFrotz - C/C++ mix
>>>Frotz - C/C++ mix
>>
>>Where are you getting your Frotz source? The copy that I have is written
>>in C, only. I haven't checked, so the headers might make provision for
>>use by C++, but that doesn't make the code any less pure. I expect that
>>WinFrotz uses C++ so that it can access the Windows GUI, but the VM is
>>just plain Frotz and that is pure C and that means that a program running
>>in the VM won't have access to any C++ insecurities that hypothetically
>>may exist.
>
> C is even slightly worse. ANSI C is mostly a subset of ANSI C++. The
> problems in these languages both come from the use of pointers, strings,
> arrays and memory buffers without rules enforcement, and you could almost
> see it as a design flaw.

Let me remind you of your original statement: "Given that most are
written in C++ which prone to overruns by design, it's more likely there
are exploitable overruns than not." I have pointed out that the VMs
themselves are written in C, not C++, so you have apparently choosen to
refashion your argument.

That's OK, I've spent some time inside the Frotz engine and it is pretty
well designed; in fact VMs generally go out of their way to enforce
rules on the bytecodes being simulated. For example, most buffer
overruns in C are caused by use of things like sprintf, which isn't used
anywhere in the VM proper. Also, every access to the VM memory is
checked to make sure that you aren't accidentally (or purposefully)
accessing past the "end of RAM" and viewing (or modifying) the
interpreter itself.

>>>It is clear from this list that C++ is it, and this is what the vast
>>>majority of players are running. Which interpreters are you talking
>>>about that aren't in C++ and used in the competition? Examples?
>>
>>It is clear that you don't know what you're talking about.
>
> It's clear you don't. They are all in C/C++ with the exception of Adrift.
> Where are the other interpreters that are non-C++? If you were basing your
> logic on the distinction between C and C++, it's erroneous.

Read your two statements again: "It is clear from this list that C++ is
it" and "They are all in C/C++". Do you see that you are changing your
own words? You started this by claiming that C++ is "prone to overruns
by design", I've called you on that statement, and now you want to say
that you really meant that there's no difference between C and C++.
Come back when you figure out what it is that you're talking about,
because I'm unable to figure it out on my own.

 

[icEDragon]

Archived from groups: rec.games.int-fiction (More info?)

>>>>A list of interpreters used in IFComp 2004 and their source language:
>>>>WinFrotz - C/C++ mix
>>>>Frotz - C/C++ mix
>>>
>>>Where are you getting your Frotz source? The copy that I have is written
>>>in C, only. I haven't checked, so the headers might make provision for
>>>use by C++, but that doesn't make the code any less pure. I expect that
>>>WinFrotz uses C++ so that it can access the Windows GUI, but the VM is
>>>just plain Frotz and that is pure C and that means that a program running
>>>in the VM won't have access to any C++ insecurities that hypothetically
>>>may exist.
>>
>> C is even slightly worse. ANSI C is mostly a subset of ANSI C++. The
>> problems in these languages both come from the use of pointers, strings,
>> arrays and memory buffers without rules enforcement, and you could almost
>> see it as a design flaw.
>
> Let me remind you of your original statement: "Given that most are
> written in C++ which prone to overruns by design, it's more likely there
> are exploitable overruns than not." I have pointed out that the VMs
> themselves are written in C, not C++, so you have apparently choosen to
> refashion your argument.

C is a subset of C++. Every one of the source packages for those in the
list that say "C++" contain .cpp files, and the _package_ contains it. You
are reducing the discussion to the parts you see as the VM. If they contain
the files, they typically use some code. Insecurities can come from trying
to format data for display through MFC.

> That's OK, I've spent some time inside the Frotz engine and it is pretty
> well designed; in fact VMs generally go out of their way to enforce rules
> on the bytecodes being simulated. For example, most buffer overruns in C
> are caused by use of things like sprintf, which isn't used anywhere in the
> VM proper. Also, every access to the VM memory is checked to make sure
> that you aren't accidentally (or purposefully) accessing past the "end of
> RAM" and viewing (or modifying) the interpreter itself.

Also: off-by-one errors in length or index, pointer arithmetic mistakes, and
more. No programmer plans his/her bugs, and if we could see them by
reviewing the source, all software would be bug free.

>>>>It is clear from this list that C++ is it, and this is what the vast
>>>>majority of players are running. Which interpreters are you talking
>>>>about that aren't in C++ and used in the competition? Examples?
>>>
>>>It is clear that you don't know what you're talking about.
>>
>> It's clear you don't. They are all in C/C++ with the exception of
>> Adrift. Where are the other interpreters that are non-C++? If you were
>> basing your logic on the distinction between C and C++, it's erroneous.
>
> Read your two statements again: "It is clear from this list that C++ is
> it" and "They are all in C/C++". Do you see that you are changing your
> own words? You started this by claiming that C++ is "prone to overruns by
> design", I've called you on that statement, and now you want to say that
> you really meant that there's no difference between C and C++. Come back
> when you figure out what it is that you're talking about, because I'm
> unable to figure it out on my own.

This is fluff. I recommend you do some reading on C and C++ and understand
the differences and similarities, because they are synonymous for this
purpose.

I disagree with you that C is somehow more safe or superior to C++,
considering C++ supports C code. That said, we agree to disagree, let's be
done with this.

 

[icEDragon]

Archived from groups: rec.games.int-fiction (More info?)

"Stephen Granade" <stephen-usenet@granades.com> wrote in message
news:m0u0mnr09h.fsf@granades.com...
> "Icedragon" <icenetREMOVETHIS@icedragon.net> writes:
>
>> A list of interpreters used in IFComp 2004 and their source language:
>> WinFrotz - C/C++ mix
>> Frotz - C/C++ mix
>> Adrift - not open source? (can't verify security, could have same
>> malware)
>> Hugo - C/C++ mix
>> ALAN - C++
>> TADS 2.x - C++
>
> TADS 2, the base Frotz distribution, the base ALAN interpreter, and
> the base HUGO interpreter are all written in C, not C++.

From the TADS website:
"The source code for TADS, written in C and C++, is freely available, so
even if an interpreter isn't already available for your system of choice,
you could port it there. The TADS source code was originally designed for
easy portability and has had its portability honed with years of experience
on a wide range of systems."
http://www.tads.org/tads.htm

Maybe the core components are C, I don't claim to have sifted through the
source code. But the documentation says it is. And it doesn't matter
either way, anyhow.

>> It is clear from this list that C++ is it, and this is what the vast
>> majority of players are running.
>
> Here I think you have inadvertently hit upon the big stumbling block
> for a single-shot .NET program: most people aren't running it. As it
> stands, most everyone will have a z-code interpreter. Many will have a
> TADS interpreter and a Hugo interpreter. That gives games written in
> those languages a two-fold advantage. One, playing such a game
> involves downloading just the game data, not a new interpreter. Your
> hypothetical .NET game requires a download of the entire engine, and
> quite probably a download of the .NET runtime. This is not a
> zero-height barrier. Two, the common language interpreters are used by
> a lot of people. So far no nasty bugs or malware have shown up from
> them. Your .NET game is an unknown quantity, and could have all kinds
> of nasty payloads attached to it.

Yes, but what ChicagoDave and I were getting at is that .Net can be set to
run in a security zone where it cannot deploy nasty payloads. An example:
run a .Net executable directly from a webpage (ie. via a link) and you fall
into the web security zone, which prohibits file access on the client
machine.

Along the lines of what you are saying, however, most people probably don't
know enough to be able to set up this kind of security when running the code
and will expose themselves to the nasty payloads.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <PSF3e.11404$k66.10752@trnddc03>,
Icedragon <icenetREMOVETHIS@icedragon.net> wrote:
>
>
>Sure, here is an example. Given that most are written in C++ which prone to
>overruns by design, it's more likely there are exploitable overruns than
>not.

Now there's the smell of horse manure.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <r%N3e.1477$1r6.1219@trnddc02>,
Icedragon <icenetREMOVETHIS@icedragon.net> wrote:
>
>My original contention: "it has already been shown that some of these tools
>had/have exploitable buffer overruns in them"
>
>Compiler == tool. If the tools for the platform have overruns, it's likely
>the environments do too.

You'll never find a more wretched hive of specious reasoning.

Because Inform had a buffer overflow (not proven exploitable), ZPlet
must also? Even though they are written by completely different
people, in totally different languages, and accomplish completely
different things?

If I thought you'd understand, I'd explain exactly why it's more
likely for Inform to have a buffer overflow than a given Z-Machine
interpreter. Or why the usual reasons given for the exploitability of
C and C++ programs are largely inapplicable to a Z-machine
interpreter. Or why a Z-machine interpreter written in C with an eye
to security would likely be safer than any given .NET program, in
terms of buffer overflows. But if you could understand, you likely
wouldn't need the explanation, so I'll save my breath.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <A9Y3e.1724$%b1.1024@trnddc08>,
Icedragon <icenetREMOVETHIS@icedragon.net> wrote:

>It's clear you don't. They are all in C/C++ with the exception of Adrift.
>Where are the other interpreters that are non-C++? If you were basing your
>logic on the distinction between C and C++, it's erroneous.

Oh, OK, I WILL waste my breath. From the point of view of certain
kinds of security, C is _safer_ than C++, because so much goes on behind the
scenes in C++, particularly constructor and destructor calls.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.

 

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 6:41 PM, Icedragon did proclaim:
> "Stephen Granade" <stephen-usenet@granades.com> wrote in message
> news:m0u0mnr09h.fsf@granades.com...
>
>>"Icedragon" <icenetREMOVETHIS@icedragon.net> writes:
>>
>>
>>>A list of interpreters used in IFComp 2004 and their source language:
>>>WinFrotz - C/C++ mix
>>>Frotz - C/C++ mix
>>>Adrift - not open source? (can't verify security, could have same
>>>malware)
>>>Hugo - C/C++ mix
>>>ALAN - C++
>>>TADS 2.x - C++
>>
>>TADS 2, the base Frotz distribution, the base ALAN interpreter, and
>>the base HUGO interpreter are all written in C, not C++.
>
>
> From the TADS website:
> "The source code for TADS, written in C and C++, is freely available, so
> even if an interpreter isn't already available for your system of choice,
> you could port it there. The TADS source code was originally designed for
> easy portability and has had its portability honed with years of experience
> on a wide range of systems."
> http://www.tads.org/tads.htm
>
> Maybe the core components are C, I don't claim to have sifted through the
> source code. But the documentation says it is. And it doesn't matter
> either way, anyhow.

I have sifted through the source code, and, actually, it does matter.
C++ is built on top of C, so by your arguments C++ may add insecurities
to what are already present in C. A VM, OTOH, is often written in a
restricted subset of C. For example, C++ allows the use of 'sprintf',
which is insecure; however a simple grep of the source indicates that
this function is not used by Frotz.

>>>It is clear from this list that C++ is it, and this is what the vast
>>>majority of players are running.
>>
>>Here I think you have inadvertently hit upon the big stumbling block
>>for a single-shot .NET program: most people aren't running it. As it
>>stands, most everyone will have a z-code interpreter. Many will have a
>>TADS interpreter and a Hugo interpreter. That gives games written in
>>those languages a two-fold advantage. One, playing such a game
>>involves downloading just the game data, not a new interpreter. Your
>>hypothetical .NET game requires a download of the entire engine, and
>>quite probably a download of the .NET runtime. This is not a
>>zero-height barrier. Two, the common language interpreters are used by
>>a lot of people. So far no nasty bugs or malware have shown up from
>>them. Your .NET game is an unknown quantity, and could have all kinds
>>of nasty payloads attached to it.
>
> Yes, but what ChicagoDave and I were getting at is that .Net can be set to
> run in a security zone where it cannot deploy nasty payloads. An example:
> run a .Net executable directly from a webpage (ie. via a link) and you fall
> into the web security zone, which prohibits file access on the client
> machine.

What do you think that the .NET CLR is written in? Before there was a
C# compiler, it was written in C and C++. Some or all of it may have
been rewritten in C# since then, but if so then it has to be using
unchecked code. By your own admissions, this is a source of possible
bugs. Java is in the same boat, and many bugs have been found that
violate the security model; these bugs have been fixed, but there is
nothing magic that could have kept them from being there in the first
place. .NET certainly has similar bugs, and (IMHO) it hasn't been
around long enough for them all to have been found.

The Z-machine has been around longer than .NET and Java put together,
and is built in the same way. All VM's implement some sort of security
zone, if for no reason that to prevent badly written byte code fom
clobbering the interpreter, and the Z-machine's has been tested for a
long time (I suspect, longer than you've been alive). I trust it a lot
more than anything written in code that MS keeps hidden from the public,
because I know MS's record on writing secure code.

And yes, you *can* run Z-code directly from a web page (at least using
Firefox and the Gnusto extension (which is written in Javascript, not C)).