From: billy on
JF Mezei <jfmezei.spamnot(a)vaxination.ca> writes:

> VMS solved the buffer overflow problem decades ago.
>
> Executable code is loaded into pages of memory that are write protected.

Even the PDP-11's Macro-11 (assembly language compiler..) has psects
(program sections) where memory regions can be set read only, as well
as defined as instructions or data, global or local, etc.

For as much as has been ripped off from DEC, it's a shame some of the
best stuff was missed, heh...

Billy Y..
From: GlennF on
On Apr 24, 4:43 am, Alec McKenzie <alecuse...(a)my-surname.me.uk> wrote:
> This is quite wrong. C is a high-level language that does not
> require programmers to manipulate memory and the CPU almost directly.
> Such requirements arise only when writing at a truly low-level such
> as assembler language or machine code.
>
> Getting things so badly wrong shows such a lack of understanding of
> what is involved as to raise serious doubts about the accuracy of
> the rest of the article.

C combines aspects of both low-level languages (an ability to avoid
abstraction and work directly with low-level system elements) and high-
level languages. You can use C as either or both a low-level and high-
level language, which is part of why it's used so extensively. In the
case of QuickTime, in particular, C is often used in plug-ins to talk
directly to hardware, acting as something higher than assembly
language, but not used in an abstracted way. So it can depend on your
programming style and needs, too.

I'm one of the editors of TidBITS where this article originally
appeared <http://db.tidbits.com/article/9579> (we allow re-use of
articles for non-commercial purposes but only when appropriately
attributed, by the way), and I'll bring this statement to the
attention of the writer and other editors so we can finesse the
statement here.
From: Jim on
In article <fuq9sq$9tg$1(a)reader2.panix.com>, billy(a)MIX.COM wrote:

> JF Mezei <jfmezei.spamnot(a)vaxination.ca> writes:
>
> > VMS solved the buffer overflow problem decades ago.
> >
> > Executable code is loaded into pages of memory that are write protected.
>
> Even the PDP-11's Macro-11 (assembly language compiler..) has psects
> (program sections) where memory regions can be set read only, as well
> as defined as instructions or data, global or local, etc.
>
> For as much as has been ripped off from DEC, it's a shame some of the
> best stuff was missed, heh...
>
> Billy Y..

I seem to remember the infamous architect of NT was Dave Cutler,
a former DEC employee. Perhaps that was why he was "former"?
(That's a joke)

psects which if memory serves me were combined csects and asects.

--
Edo ergo sum
From: billy on
Jim <no(a)spam.plz> writes:

> I seem to remember the infamous architect of NT was Dave Cutler,
> a former DEC employee. Perhaps that was why he was "former"?
> (That's a joke)

Yea, I remember when some of my VMS friends were really enthused
about how NT was going to be the hot new hip thing in the world of
OS's. Not any more, though. I never bought into that - I'm still
using VMS.

> psects which if memory serves me were combined csects and asects.

Psect was, I believe, for RSX (from whence VMS came), and csect was
for some other operating systems, but as I recall they are the same
(other than what their default parameters are), and psect has worked
under RT-11 for a long time, too. Asect is a convenient way to place
code at an absolute address via its default section name (. ABS.).

Billy Y..
From: Priam on
The zara a �crit :

> "Michelle Steiner" <michelle(a)michelle.org> wrote in message
> news:michelle-38EEFC.14094423042008(a)news.west.cox.net...
>> About the OS component called QuickTime.

>> (...)

>> The result is that even though the
>> Java parts of QuickTime are pretty secure, attackers take advantage of
>> these complex handoffs and all the other bits and plug-ins programmed in
>> C.

(...)

>> With QuickTime 7.4.5,
>> Apple added ASLR support to QuickTime, also moving around many of the
>> QuickTime commands every time it runs. This keeps the attacker from
>> being able to point back to any QuickTime commands and using that to
>> take over the computer. Apple didn't enable this for all of QuickTime's
>> commands, so QuickTime is still a little vulnerable, but it's a major
>> step forward.
>>
>> Apple included their own version of ASLR in Mac OS X 10.5 Leopard, but
>> it doesn't work quite as well as Vista's. Called Library Randomization,
>> it doesn't rearrange all the core system commands, and in particular it
>> leaves fixed in place something called a dynamic linker that an attacker
>> can still use to exploit the Mac. We're hoping Apple will fix this in a
>> future update.

(...)

>> One area that will always present a potential problem for QuickTime is
>> third-party plug-ins for new media types. Since Apple doesn't write or
>> distribute these, there are no guarantees the programmers of said
>> plug-ins will take the same precautions as Apple's engineers. It's one
>> reason you want to be careful about installing third-party plug-ins.

To Michelle Steiner. When you quote an article, it's nice to give the
URL. Even though you copy it entirely here, sometimes updates are made:

<http://db.tidbits.com/article/9579>

> Interesting; AV security for a system that supposedly has no security
> issues. In Apples case it's not called "AV security", but rather "patch"

Zara, try to be honest. Usually, all Steiner does is throw insult upon
insult, but here, she provides a very insightful article from somebody
who's both competent and an excellent vulgarizer, a rather rare
combination. This is not just Mac praise and extravaganza. It's the
plain facts. It does say that Mac systems are vulnerable, something that
many Mac users here contested. Why it is vulnerable, just as any other
OS, is explained. I find it's worhty contribution. I enjoyed reading
this article.

Otherwise, rest assured that, as far as security is concerned, a
security patch does the job as much as if it had been applied in the
original release. Better late than never, that's all.