Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.misc > #2224 > unrolled thread

RISC OS hits OSNews

Back to article view | Back to comp.sys.acorn.misc

Contents

  RISC OS hits OSNews patric <patric@invalid.net> - 2011-10-31 18:30 +0000
    Re: RISC OS hits OSNews Martin Hansen <mhh@shrewsbury.org.uk> - 2011-10-31 12:10 -0700
      Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-10-31 20:15 +0000
        Re: RISC OS hits OSNews Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-10-31 19:49 +0000
          Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-10-31 20:45 +0000
          Re: RISC OS hits OSNews "Ste (news)" <steve@revi11.plus.com> - 2011-11-01 12:59 +0000
            Re: RISC OS hits OSNews trevj <trevj@cwazy.co.uk> - 2011-11-01 09:03 -0700
              Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-01 17:38 +0000
            Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-01 20:57 +0100
              Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-01 21:11 +0000
                Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-01 22:45 +0000
                  Re: RISC OS hits OSNews "Ste (news)" <steve@revi11.plus.com> - 2011-11-01 23:58 +0000
                    Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-02 00:48 +0000
                    Re: RISC OS hits OSNews M Harding <riscos@mdharding.org.uk> - 2011-11-02 16:08 +0000
                      Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-02 18:23 +0100
                        Re: RISC OS hits OSNews Folderol <folderol@ukfsn.org> - 2011-11-02 18:22 +0000
                          Re: RISC OS hits OSNews David H Wild <dhwild@talktalk.net> - 2011-11-02 19:24 +0000
                          Re: RISC OS hits OSNews Tony Moore <old_coaster@yahoo.co.uk> - 2011-11-02 19:33 +0000
                            Re: RISC OS hits OSNews Folderol <folderol@ukfsn.org> - 2011-11-02 19:40 +0000
                          Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-03 19:49 +0100
                            Re: RISC OS hits OSNews druck <news@druck.org.uk> - 2011-11-03 19:49 +0000
                    Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-02 18:08 +0100
                  Re: RISC OS hits OSNews trevj <trevj@cwazy.co.uk> - 2011-11-02 02:19 -0700
                    Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-03 01:52 +0000
                      Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-03 19:54 +0100
                        Re: RISC OS hits OSNews trevj <trevj@cwazy.co.uk> - 2011-11-03 13:27 -0700
                          Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-03 21:41 +0000
                            Re: RISC OS hits OSNews trevj <trevj@cwazy.co.uk> - 2011-11-04 01:16 -0700
                          Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-04 07:03 +0100
                Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-02 19:00 +0100
                  Re: RISC OS hits OSNews Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-11-03 00:21 +0000
                    Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-03 01:31 +0000
                    Re: RISC OS hits OSNews patric <patric@invalid.net> - 2011-11-03 02:24 +0000
              Re: RISC OS hits OSNews Jess <phantasm_39@hotmail.com> - 2011-11-01 22:26 +0000
                Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-02 18:34 +0100
                  Re: RISC OS hits OSNews Jess <phantasm_39@hotmail.com> - 2011-11-02 21:51 +0000
                    Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-03 20:03 +0100
                    Re: RISC OS hits OSNews Stewart Brodie <stewart.brodie@ntlworld.com> - 2011-11-04 01:24 +0000
                      Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-04 07:20 +0100
                        Re: RISC OS hits OSNews Stewart Brodie <stewart.brodie@ntlworld.com> - 2011-11-05 00:56 +0000
                          Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-05 07:18 +0100
                            Re: RISC OS hits OSNews Stewart Brodie <stewart.brodie@ntlworld.com> - 2011-11-05 20:59 +0000
                              Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-07 05:06 +0100
                          Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-15 19:32 +0100
                      Re: RISC OS hits OSNews Jess <phantasm_39@hotmail.com> - 2011-11-04 09:22 +0000
                        Re: RISC OS hits OSNews Stewart Brodie <stewart.brodie@ntlworld.com> - 2011-11-04 22:53 +0000
                          Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-05 07:23 +0100
                          Re: RISC OS hits OSNews Jess <phantasm_39@hotmail.com> - 2011-11-06 12:48 +0000
                  Re: RISC OS hits OSNews Harriet Bazley <bazley@feathermail.co.uk> - 2011-11-22 00:19 +0000
          Re: RISC OS hits OSNews Tim Hill <tim@invalid.org.uk> - 2011-11-06 07:02 +0000
        Re: RISC OS hits OSNews Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-01 20:35 +0100
      Re: RISC OS hits OSNews Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-10-31 20:09 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#2315

On 05/11/2011 01:56, Stewart Brodie wrote:

> To program in C requires discipline.

Here, let me fix that for you.

   To program requires discipline.


> Undisciplined and/or incompetent programmers are a menace whatever language
> they are using.

I think you shouldn't lose track of the fact that we are humans creating 
something large and complicated.

Consider, if you will, OvationPro. It's the work of one man. It is big 
and complicated and he's the master of it all. Now consider your day to 
day speech and human interactions. Has anybody misunderstood something 
you said today (no matter how trivial), or have you had something that 
in hindsight could have been expressed better? We routinely make 
mistakes and errors and now we're dealing with something that has 
absolutely ZERO tolerance for error.


> They are uniquely gifted in creating horrible disasters on a grand scale.

Well, you gotta admit that a messed up bit of punctuation leading to the 
self-destruction of a space-bound rocket is the very definition of the 
word "epic" (and, by consequence, an "epic fail"), however I think 
people who may be tired or fed up or both under a rushed deadline have 
yet to grasp the significance of the potential failures their coding 
could bring about. It's not just rockets, it's ECUs, brakes, railway 
monitoring, electronic voting, satnav, etc etc. Try seeing if you can 
get the comp.risks news feed. It periodically lists a digest of the good 
ones, and frankly some are complete show stoppers.


> Often, the "safer" the language, the grander the scale.

I disagree. I think stuff such a buffer overruns and use of 
uninitialised pointers will bite us in the ass for years to come. Let's 
face it, my car's brakes could be managed by an ARM or a PIC or an 
Atemel running some compiled C. It is *NOT* being to be running a 
compiled VisualBasic app.

Windows (XP) gave the world the grand stupidity of a default account 
with admin priv.

C gave the world the grand stupidity of a language that makes ZERO 
attempt at array or pointer checking without patching in third party 
stuff, if available.
Many modern compilers will report if they think a pointer is used before 
it is initialised, but I've yet to use one that had an option to compile 
in subscript validation. I'm not asking for checking to be standard, but 
it would be nice to have it as an option while developing. Who hasn't 
encountered a "Subscript out of range" error in BASIC at some point? At 
least BASIC will attempt to fault it, not trample over stuff regardless.


> I'm not disputing that RISC OS is beyond help - it's clearly hopeless.

I don't know, rigidly enforced memory permissions and making OS_EnterOS 
need some sort of access process may give a reasonable attempt at 
process security without chucking away and rewriting the entire system 
(which nobody is going to do).


> I'm just challenging the bizarre belief that having a browser that supports
> ECMAScript makes the slightest difference to any of this.

I think the logic is that the more braindead a browser is, the fewer 
points of potential vulnerability exist. I *hope* the original poster 
doesn't think trojans and such are actually written in JavaScript!

That said, recent Operas (10.something, prob. previous too) have been 
shown to be vulnerable to gibberish Content-Length in the header, plus 
scripting ridiculously large strings, etc.


> Or, in fact, no more of a problem than any other piece of code on your
> system.

Actually, it is. My keyboard driver is a "sealed unit" used only by me. 
I could learn if it has any weakness (like if I hold these six keys 
down...), however it is local code for a local device.

A browser script interpreter, however, routinely deals with shocking 
masses of code from god-only-knows where, a large amount of which is 
utter $#!+ (look at your browser's scripting console or error log, 
you'll see lots, and equally lots of crap CSS).

Take a look at: http://www.exploit-db.com/exploits/11332/


> It's still nothing to do with ECMAScript in browsers.  Or
> even browsers in particular.

Mmmm, are you not in danger of missing the wood for the trees here? Yes, 
many things offer potential vulnerabilities, but yes - you should accept 
that *some* things are used as "gateway" items. One of which is a 
browser, a subset of which is the script engine.

I suspect the font render issue is because the modern browsers support 
downloading of custom fonts - which is sort of taking a font file of 
unknown provenance and throwing it to a font render system that hasn't 
exactly been stress tested.


>> We could extrapolate beyond this point and ask questions like "what does
>> [Oregano|Fresco|NetSurf] do if you give it malformed JPEG or PNG data?
> Or your mail client, or news reader or in fact, any piece of software that
> processes an image.

Actually, very little. :-)

Thunderbird does not fetch remote content, and "Display attachments 
inline" is not ticked, so malformed JPEGs will be ignored. If the 
message isn't from somebody I know, or has content that looks "unusual", 
it is terminated (with extreme prejudice).


>> It isn't the scripting, per se, it is what weaknesses it could expose.
> Does that mean that you agree with me that is ridiculous to single out
> ECMAScript, especially given its sandboxed nature because, in my opinion, it
> is far less likely to be the source of any attack than many other trivially
> exploitable mechanisms?

I'm not sure I would agree it is "far less likely", but certainly it is 
one of many potential mechanisms; and indeed the JavaScript engine in 
Adobe Reader is the source of a fair few of the PDF vulns. God knows why 
a *DOCUMENT* format needs a flippin' script interpreter, but there you go...

You will, however, need to agree with me that the browser and the script 
interpreter itself are going to be highly vulnerable to attack as they 
are the world-facing part of the computer. Let's face it, there could be 
a glaring exploit in OvationPro, or Impression, or Edit, or TechWriter, 
or Paint... but to make use of this, we need to get a document into the 
hands of our user AND get them to load it. It is much nicer (from an 
"I'm an asshole" point of view) to look for flaws in the browser, script 
engine, and typical plug-ins so that the exploit can be immediate and 
effective.

Browser/script - susceptible to be an attack vector due to the 
world-facing nature. But by no means the ONLY vector. Don't tell me that 
scripting being sandboxed makes it safe, I have read about a virtualised 
machine being capable of infecting its host; because when you think 
about it, a sandbox (or virtual setup) is just another piece of code...


The concern here is the more the browser tries to do (such as scripting, 
but equally CSS or HTML5ish stuff), the more that can happen. This isn't 
to say it isn't worthwhile, think how we'd be if our state of the art 
was Termite's browser - it's just... for some code, a moment of laziness 
will be no big deal. For other code, it must be checked over and over 
and over. The browser is one thing I'd want to be bulletproof, the 
filesystem is another. I trust you understand why. ;-)


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2324

Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 05/11/2011 01:56, Stewart Brodie wrote:
> 
> > To program in C requires discipline.
> 
> Here, let me fix that for you.
> 
>    To program requires discipline.

I notice that you managed to snip/ignore my comment that described that you
can substitute pretty much any language for C in my statement.  I only put C
in that first sentence in response to your rant about C programmers.


> Try seeing if you can get the comp.risks news feed. It periodically lists
> a digest of the good ones, and frankly some are complete show stoppers.

I've been on the mailing list for very many years - I recommend it to
everybody who works on or with computers.  However, there's only the
occasional really good one nowadays - so many are the same issue occurring
again and again.  It's depressing, really.


> C gave the world the grand stupidity of a language that makes ZERO 
> attempt at array or pointer checking [..]

I disagree strongly.  It's not stupidity at all.  What you have to
understand is that all languages will have been designed for a specific
purpose with set of design goals.  In C's case, it was as a systems language
that provides a level of portability but without getting in the way of the
programmer.

Other languages are designed for other purposes - use the appropriate
language.


> [More ranting about C's design snipped] Who hasn't encountered a
> "Subscript out of range" error in BASIC at some point? At least BASIC will
> attempt to fault it, not trample over stuff regardless.

Other languages are designed for other purposes - use the appropriate
language.

BBC BASIC is an interpreted language that detects this error at run-time; C
is a compiled language that does not, although C compiler can, in some
circumstances, detect and report these problems at compile-time.


> > I'm not disputing that RISC OS is beyond help - it's clearly hopeless.
> 
> I don't know, rigidly enforced memory permissions and making OS_EnterOS
> need some sort of access process may give a reasonable attempt at process
> security without chucking away and rewriting the entire system (which
> nobody is going to do).

Good luck.  I still maintain it's utterly hopeless.


> > I'm just challenging the bizarre belief that having a browser that
> > supports ECMAScript makes the slightest difference to any of this.
> 
> I think the logic is that the more braindead a browser is, the fewer 
> points of potential vulnerability exist. I *hope* the original poster 
> doesn't think trojans and such are actually written in JavaScript!

Who knows?  There's been enough FUD about JavaScript on these groups over
the past 10+ years that you could probably convince some of them of
anything.


> That said, recent Operas (10.something, prob. previous too) have been 
> shown to be vulnerable to gibberish Content-Length in the header, plus 
> scripting ridiculously large strings, etc.

For (hopefully) obvious reasons, I don't want to comment on Opera
specifically, but stick to browser technology generically.

Browsers have a relatively small number of external inputs and outputs to
control, so validation of "corrupt" data can be confined to a relatively
small area of code (in the overall scheme of browser size, that is).  Other
problems such as attempting DoS with infinite loops in scripts or
excessively large data sets are a separate class of problem, which need to
be dealt with separately.


> > Or, in fact, no more of a problem than any other piece of code on your
> > system.
> 
> Actually, it is. My keyboard driver is a "sealed unit" used only by me. 
> I could learn if it has any weakness (like if I hold these six keys 
> down...), however it is local code for a local device.

Wasn't it Apple keyboards that hosted viruses that spread to the host
machine?  See comp.risks passim.


> A browser script interpreter, however, routinely deals with shocking 
> masses of code from god-only-knows where, a large amount of which is 
> utter $#!+ (look at your browser's scripting console or error log, 
> you'll see lots, and equally lots of crap CSS).

It is hard for people who don't understand these web technologies to
interpret the messages that you find in such error logs.

I imagine that most of the "errors" in your CSS logs aren't actual errors in
the CSS, but warnings regarding unknown properties which your browser does
not yet understand or for compatibility purposes (e.g. "real" properties
with an underscore on the front of the name) or properties that your browser
no longer supports.  Sometimes you find real errors, but in my very long
experience of it, these are quite rare nowadays.

Even scripting "errors" are usually not the fault of the script, but caused
by unexpected behaviour of a DOM method or property.


> > It's still nothing to do with ECMAScript in browsers.  Or
> > even browsers in particular.
> 
> Mmmm, are you not in danger of missing the wood for the trees here?

Not at all - the poster to whom I replied originally stated that RISC OS was
better off without a browser that supports JavaScript because it would make
the OS less secure.  I find that position to be utterly absurd.


> Yes, many things offer potential vulnerabilities, but yes - you should
> accept that *some* things are used as "gateway" items. One of which is a
> browser, a subset of which is the script engine.

Of course, however, it remains just a *very small* subset.  It's simply
complete nonsense to fear one tiny part of one application, *especially* on
RISC OS, where the barn doesn't even have a door.


> I suspect the font render issue is because the modern browsers support 
> downloading of custom fonts - which is sort of taking a font file of 
> unknown provenance and throwing it to a font render system that hasn't 
> exactly been stress tested.

If you think browsers are the only applications that download fonts, you
would be wrong.  I don't know whether the second part of what you wrote is
true or not - should I assume that you have extensive experience of font
engine testing (either within or independently of any browser)?


> > > We could extrapolate beyond this point and ask questions like "what
> > > does [Oregano|Fresco|NetSurf] do if you give it malformed JPEG or PNG
> > > data?
> > Or your mail client, or news reader or in fact, any piece of software
> > that processes an image.
> 
> Actually, very little. :-)

> Thunderbird does not fetch remote content, and "Display attachments 
> inline" is not ticked, so malformed JPEGs will be ignored. If the 
> message isn't from somebody I know, or has content that looks "unusual", 
> it is terminated (with extreme prejudice).

You are just as vulnerable like that as running a browser that displays
content.  Why do you think it's only attachments that are the problem?   An
e-mail client needs to deal with byte sequences in any of a number of
encodings and an error there can cause the sort of vulnerabilities.


> >> It isn't the scripting, per se, it is what weaknesses it could expose.
> > Does that mean that you agree with me that is ridiculous to single out
> > ECMAScript, especially given its sandboxed nature because, in my
> > opinion, it is far less likely to be the source of any attack than many
> > other trivially exploitable mechanisms?
> 
> I'm not sure I would agree it is "far less likely", but certainly it is
> one of many potential mechanisms; and indeed the JavaScript engine in
> Adobe Reader is the source of a fair few of the PDF vulns. God knows why a
> *DOCUMENT* format needs a flippin' script interpreter, but there you go...

Adobe Reader is not a browser.  Adobe's track record in security is, of
course, worse than Microsoft's nowadays (which is a real achievement)


> You will, however, need to agree with me that the browser and the script 
> interpreter itself are going to be highly vulnerable to attack as they 
> are the world-facing part of the computer.

No, they are not highly vulnerable.  They are liable to be attacked, because
they're on the second line of defence in your computer.  That's two
completely different things.  They only cause vulnerability if they fail to
stop attacks.

> Let's face it, there could be a glaring exploit in OvationPro, or
> Impression, or Edit, or TechWriter, or Paint... but to make use of this,
> we need to get a document into the hands of our user AND get them to load
> it.

Easily done by anybody distributing software (or fonts, as we've already
discovered), but yes, it does require more active action by the user.


> It is much nicer (from an "I'm an asshole" point of view) to look for
> flaws in the browser, script engine, and typical plug-ins so that the
> exploit can be immediate and effective.
>
> Browser/script - susceptible to be an attack vector due to the 
> world-facing nature. But by no means the ONLY vector. Don't tell me that 
> scripting being sandboxed makes it safe, I have read about a virtualised 
> machine being capable of infecting its host; because when you think 
> about it, a sandbox (or virtual setup) is just another piece of code...

You dispute that the controlled environment within which browsers execute
scripts is safe because some completely separate technology is vulnerable.
I don't understand that illogical leap, sorry.


> The concern here is the more the browser tries to do (such as scripting, 
> but equally CSS or HTML5ish stuff), the more that can happen.

LOL.  FUD.


> This isn't to say it isn't worthwhile, think how we'd be if our state of
> the art was Termite's browser - it's just... for some code, a moment of
> laziness will be no big deal.

I vaguely remember the name, but never used it.  I'm not sure what you're
saying there at the end.


> For other code, it must be checked over and over and over. The browser is
> one thing I'd want to be bulletproof, the filesystem is another. I trust
> you understand why. ;-)

Are you saying you trust FileSwitch??


-- 
Stewart Brodie

[toc] | [prev] | [next] | [standalone]

#2342

On 05/11/2011 21:59, Stewart Brodie wrote:

> I notice that you managed to snip/ignore my comment that described that you
> can substitute pretty much any language for C in my statement.  I only put C
> in that first sentence in response to your rant about C programmers.

:-) It was more a rant about *C* itself.


> so many are the same issue occurring again and again.  It's depressing, really.

Tell me about it. Buffer overflow? Check. SQL injection? Check. Oughtn't 
there be, like, a book "Scripted websites for dummies" or something that 
provides a list of things NOT to do?


> In C's case, it was as a systems language that provides a level of portability
> but without getting in the way of the programmer.

It would not *HURT* to have an option to drop in bounds checking. Many 
compilers are quite happy to drop in profiling hooks for you [*], but 
not the checking. Why is this?

* - and on some PC compilers, you can get stack frame checking and
     other stuff that's in some dark dusty part of the manual...


> Other languages are designed for other purposes - use the appropriate
> language.

Are you willing to point that out to everybody that uses C because it 
is, usually, the nicer option? !Edit? Written in C. Thunderbird? Take a 
guess. Duke Nukem (original) and Quake are big piles of C code. You 
*could* have written it all in Pascal or Ada, but then you *could* write 
a web browser in BASIC (and somebody did). I think you'll need to think 
beyond what C was originally to what it became. It's been tweaked 
numerous times in its life, one might day pretentions of "systems 
language" was gone in the change between K&R and ANSI/ISO when people 
started to use C for many many varied things.


> BBC BASIC is an interpreted language that detects this error at run-time;

Pascal is a compiled language that detects this error at run-time. And 
in some Pascals, you can turn it off.


> For (hopefully) obvious reasons, I don't want to comment on Opera
> specifically, but stick to browser technology generically.

Fair enough, I only picked Opera as I remembered something recently on 
ElReg where Opera was killable from an HTTP response header, which was 
amusing for all the fanboi reaction (on both sides).


> Other problems such as attempting DoS with infinite loops in scripts or
> excessively large data sets are a separate class of problem, which need to
> be dealt with separately.

The interpreter itself ought to flag up this on a timer (or sanitising 
data set requests prior to attempting allocation).
Anybody remember the Fresco "takesages" message? :-)


> Wasn't it Apple keyboards that hosted viruses that spread to the host
> machine?  See comp.risks passim.

:-) Which relied upon the mark receiving a specially-modified keyboard 
and then being convinced to use it. Same deal, IIRC, for Firewire.

Thing is, this is getting yourself (or a device on your behalf) 
*physical* access to the machine. Not a remote prod. So it's a whole 
different set of issues.


> It is hard for people who don't understand these web technologies to
> interpret the messages that you find in such error logs.

Example:
--8<--------
Warning: Empty string passed to getElementById().

Warning: XUL box for div element contained an inline #text child, 
forcing all its children to be wrapped in a block.  This can often be 
fixed by replacing "display: -moz-inline-box" with "display: 
-moz-inline-box; display: inline-block".
Source File: [omitted]
Line: 0

Error: $("fid-overuse_block_true") is null
Source File: [omitted]
Line: 86
--8<--------

On loading and using the one site, there's 16 *screenfuls* of reports. 
Most are warnings, a couple are errors.


> Even scripting "errors" are usually not the fault of the script, but caused
> by unexpected behaviour of a DOM method or property.

Mmm, M&S throws a few - possibly due to NoScript blocking. CNN errors a 
lot, same reason I'd expect.

Microsoft.com throws an interesting one:
--8<--------
Error: The stylesheet 
http://c.microsoft.com/trans_pixel.aspx?tz=-1&cot=5&qos.uri=http://www.microsoft.com/en-us/default.aspx&qos.ti=1320636882343&ts=1320636882344&qos.tl=&qos.n=init 
was not loaded because its MIME type, "image/gif", is not "text/css".
Source File: http://www.microsoft.com/en-us/default.aspx
Line: 0
--8<--------


> Not at all - the poster to whom I replied originally stated that RISC OS was
> better off without a browser that supports JavaScript because it would make
> the OS less secure.  I find that position to be utterly absurd.

Flip side of the coin, the more such technologies are in use, the more 
the platform will be left behind. Why happens when World+Kitten makes 
the shift to HTML5? Or, frankly more likely, IPv6. Is there even IPv6 
support in RISC OS?


> *especially* on RISC OS, where the barn doesn't even have a door.

ROTFL! Nice analogy. :-)


> If you think browsers are the only applications that download fonts, you
> would be wrong.

I may well be wrong, does Skype do this? Pretty much the only other 
vector on *my* system (can't speak for others) is if there are embedded 
fonts in PDF files. Or have I missed something?


> should I assume that you have extensive experience of font
> engine testing (either within or independently of any browser)?

No, I'm extrapolating from this being, IIRC, the third time the font 
rendering has been a target. This time, however, it seems a fairly nasty 
exploit. But, then, the WMF one (much the same idea, actually, 
specifically broken objects tripping up kernel rendering) had 
possibilities to bypass user privilege settings too, didn't it?


> Why do you think it's only attachments that are the problem?

I don't.


> An e-mail client needs to deal with byte sequences in any of a number of
> encodings and an error there can cause the sort of vulnerabilities.

True. However given that said byte sequences are likely to be the email 
data, there's a limit to how much can be blocked or turned off.


> Adobe Reader is not a browser.

But it has JavaScript. Go figure.


> Adobe's track record in security is, of course, worse than Microsoft's nowadays
> (which is a real achievement)

Hehe, yeah. And between Reader and Flash, that's two of the most common 
web technologies handled by the company with a null track record in 
security. Oops!


> I don't understand that illogical leap, sorry.

Simple, you were saying that scripting is "safe" because it occurs in a 
sandboxed environment. The fact that exploits have in fact used the 
script engine as a point of entry implies one of two things:
   1. There was actually no sandbox on that browser.
or:
   2. The sandbox protection was compromised.

The point being that, whatever and however the sandbox works, it is 
usually just another level of code. There may or may not be hardware 
features (damn rigid memory protection, DEP, etc) to help.

It isn't illogical, it is looking at the system from the point of view 
of an attacker and seeing that it's just another door to kick down, not 
some magic solution.


>> The concern here is the more the browser tries to do (such as scripting,
>> but equally CSS or HTML5ish stuff), the more that can happen.
> LOL.  FUD.

We'll see. It's easy to handwave with "FUD" and saying that input 
handling is a fairly small part of the code of a browser, and indeed 
things have improved since the days when Word macro attacks did the 
rounds regularly - but that we still have regular warnings on Windows 
core parts, IE8, Flash, and Reader (not to mention a plethora of others) 
means that there are many many holes in existence. FUD? Try looking at:
   http://www.theregister.co.uk/security/malware/
for a selection, count the number of times 0-day appears. Frankly, I 
value my data (and time) more to write off something as mere "FUD" and 
disregard it.


>> This isn't to say it isn't worthwhile, think how we'd be if our state of
>> the art was Termite's browser - it's just... for some code, a moment of
>> laziness will be no big deal.
> I vaguely remember the name, but never used it.  I'm not sure what you're
> saying there at the end.

Hint: It supports HTML2.0. Only.


> Are you saying you trust FileSwitch??

A hell of a lot more than I trust FAT.

Infinitely more than I trust anything Microsoft has ever written that is 
supposed to repair FAT errors.

...oh look, something on this USB stick has screwed up. Let's run chkdsk 
to see what's what? Oh look, vfat-something-or-other has just died.

Or:

...oh look, something on this USD stick is messed up. Let's run 
chkdsk... good, good, fixed.
Later: Oh crap! It "fixed" it by writing a load of null bytes into 
damaged files and NOT bothering to say which files were affected. 
Awesomely useful when it is stuff like .exe files!


What were you saying about FileSwitch? ;-)



Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2514

On 05/11/2011 01:56, Stewart Brodie wrote:

> Does that mean that you agree with me that is ridiculous to single out
> ECMAScript, especially given its sandboxed nature because, in my opinion,
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
As I said, a "sandbox" is just another layer of code to overcome. It is 
not some sort of magical security solution. It is better than nothing, 
but relying on it to be impenetrable is rather unwise.

http://www.theregister.co.uk/2011/11/15/apple_sandbox_security_fail/

Debatable whether or not this is a sandbox fail or an implementation 
fail. Frankly, if a supposedly locked-down program can get access to 
stuff it shouldn't, then symantic differences are mere trivia.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2304

In message <gemini.lu43x0001qfxe0398.stewart.brodie@ntlworld.com>
          Stewart Brodie <stewart.brodie@ntlworld.com> wrote:

> Jess <phantasm_39@hotmail.com> wrote:

>> It has occurred to me, that with the lack of internal security on RISC OS,
>> it probably isn't a good idea having a javascript enabled browser, if
>> there is any big takeup of the system.

> What is it that you believe it can do outside the boundaries imposed by the
> browser?

Exactly what it does on Windows (and Macs to a lesser extent). Exploit 
any vulnerability in the security of the browser, and then you are 
left with the internal system security.

(What's to stop it saving an app with a nasty !boot, somewhere)


-- 
Jess                   Iyonix

[toc] | [prev] | [next] | [standalone]

#2312

Jess <phantasm_39@hotmail.com> wrote:

> In message <gemini.lu43x0001qfxe0398.stewart.brodie@ntlworld.com>
>           Stewart Brodie <stewart.brodie@ntlworld.com> wrote:
> 
> > Jess <phantasm_39@hotmail.com> wrote:
> 
> >> It has occurred to me, that with the lack of internal security on RISC
OS,
> >> it probably isn't a good idea having a javascript enabled browser, if
> >> there is any big takeup of the system.
> 
> > What is it that you believe it can do outside the boundaries imposed by
> > the browser?
> 
> Exactly what it does on Windows (and Macs to a lesser extent). Exploit any
> vulnerability in the security of the browser, and then you are left with
> the internal system security.
> 
> (What's to stop it saving an app with a nasty !boot, somewhere)

What's to stop your newsreader doing the same, or your mail client, or your
NTP client?    Perhaps you'd better disconnect from the Internet
immediately, lest you catch something.  ECMAScript in the web browser
sandbox is the least of your worries.


-- 
Stewart Brodie

[toc] | [prev] | [next] | [standalone]

#2316

On 04/11/2011 23:53, Stewart Brodie wrote:

> Perhaps you'd better disconnect from the Internet immediately,
> lest you catch something.

Of *all* my computers, only *ONE* has direct access to the Internet. :-)


> ECMAScript in the web browser sandbox is the least of your worries.

Funny, I'm running NoScript on my browser, which specifically filters 
out scripting. Long boring technical explanations that have little to do 
with RISC OS, plus the water has come up so I'm going to have a bath 
after a horrible week at work where I spent Tuesday (public holiday) at 
a big university hospital thanks to *one* itty-bitty drop of "Delladet" 
(VS2, Google if you care...) in my eye. Let's just say it was a day I'd 
rather forget. So, I'm off to soak and... RELAX!


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2333

In message <gemini.lu5rlk004vmp9010k.stewart.brodie@ntlworld.com>
          Stewart Brodie <stewart.brodie@ntlworld.com> wrote:

>> Exactly what it does on Windows (and Macs to a lesser extent). Exploit any
>> vulnerability in the security of the browser, and then you are left with
>> the internal system security.
>> 
>> (What's to stop it saving an app with a nasty !boot, somewhere)

> What's to stop your newsreader doing the same, or your mail client, or your
> NTP client?    Perhaps you'd better disconnect from the Internet

The fact that they have no scripting language, so the best they can do 
is try and con me into doing something stupid. (Unless they can do 
some sort of buffer overflow and execute some code, which apparently 
isn't easy to do on strongarms.)

> immediately, lest you catch something.  ECMAScript in the web browser
> sandbox is the least of your worries.

The worry is if it climbs out of the sandbox into the system. Which is 
why I run noscript or notscripts on most of my browsers.

-- 
Jess                   Iyonix

[toc] | [prev] | [next] | [standalone]

#2643

On 2 Nov 2011 as I do recall,
          Rick Murray  wrote:

[snip]

> For the record, I'm looking to get a Model B. It will NOT be running
> RISC OS. I plan to set up a web server, mount the thing *physically*
> inside my Livebox, and then leave it running in there.
>
> However, given the price, I can probably justify a Model A (or a second
> Model B) for playing with. That might see some RISC OS action... :-)
>
When I first read that, I assumed you were going to be mounting the Pi
inside the BBC Model A....   ;-D

-- 
Harriet Bazley                     ==  Loyaulte me lie ==

Those who neglect the past do not deserve the future.

[toc] | [prev] | [next] | [standalone]

#2327

In article <9LA*R77Qt@news.chiark.greenend.org.uk>, Theo Markettos
<theom+news@chiark.greenend.org.uk> wrote:
> Particularly relevant is documentation of modern
> languages/libraries/etc... tutorials that appeared in Acorn User in
> 1993 are probably a little outdated now, as is the assumption that
> everyone starts by programming in BASIC.

Some things never change. When the BBC B was released, people were saying
BASIC was outdated and we should all be writing in the sea or somesuch.

Accessibility is the key. BBC BASIC is just THERE and nothing else is. To
use the over worn motoring analogy, not many people would buy the model
of car they drove to learn and pass their test. Once kids of 10 master
BASIC and LOGO they can move on to something {more grown up};

-- 
Tim Hill of timil.com . . .
* supports TFT & shares in cheaper ethical telecoms http://tjrh.eu/phone
* has a genuine & spam-proof address for Usenet http://www.invalid.org.uk/
* accepts incoming email: substitute postmaster@ for tim@

... "What is best, that best I wish in thee" Troilus & C, Act ii, Sc.2

[toc] | [prev] | [next] | [standalone]

#2253

On 31/10/2011 21:15, patric wrote:

> one stop documentation to go with it. BBC Basic, d'n'd, the GUI and that
> is all fine but we need to point people to the wealth of relevant stuff
> available. Modern things like RiscLua for example.

I'd give a definite +1 here.

Example - my slowly developing ARMwiki. I've got a tutorial on setting 
up RISC OS on an emulator to get an ARM operating system running in a 
virtual ARM system. Makes sense, right?

Okay. Show me the user guide.

I guess it says a lot about the geekiness of RISC OS users that we have 
full PDFs of the ever-increasingly-outdated PRMs, but nothing about the 
system user guide. How do we explain "window furniture" to a newbie? How 
about the "where the hell is my application?!" for stuff loaded appears 
on the icon bar and doesn't usually auto-open a blank window. The fact 
that clicking in a window *will* give it input, but *won't* pop it to 
the top. The fact that the (rather lovely IMHO) filesystem is like 
nothing else on earth - the diametric opposite of the Unix "/" with 
mounted directories, and a whole evolution beyond Windows C:, D:, E:, etc.

Where can we point new users to a definite place to explain the ins and 
outs of the system?


Does anybody have the official user guide in an editable electronic form 
(& rights) so it can be updated for RISC OS 5?


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2233

The following bytes were arranged on 31 Oct 2011 by Martin Hansen :

> For those not on twitter, "Raspberry Pi to embrace RISC OS" is
> on the RISC OScode website.

"Alan *Wriggley*"?!

-- 
  __<^>__
 / _   _ \  I don't have a problem with God; it's his fan club I can't stand.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.sys.acorn.misc

csiph-web