Norton Internet Security / Norton AntiVirus

[AllenM Norton Fighter]

---

joen wrote:

hu: > It's presumably not something like dimensioning a matrix as one had to do back when I programmed in HPBasic?

Maybe, maybe not.  Why don't they increase the size of the array, recompile, test, and let us know if that worked or didn't work?

_Some_ (technical) info would be welcome.  Rather than treating everyone like mushrooms.

Has anyone been contacted by that "advanced technician" mentioned by CS a while back?  lol

---

Sorry but this is way too simplistic.... As a software engineer I can tell you that if you simply overrun an array bounds you are now writing outside the memory region the OS has given to you and you would crash every single time at the same point. It would not be hit and miss.

[joen]

MB:

> 2012 Version is not in Beta

It would be difficult to convince many customers of that.

> Beta for 2012 version was over last year.

You have _completely_ missed the point of this thread.

Consider the following:

19.1.1.3

19.1.0.28

19.2.0.10

19.5.0.145

19.5.1.2

19.6.1.8

19.6.2.10

19.7.0.9

19.7.1.5

(There are probably some that I missed.)

It's slow.  It still has some major problems.

Objectively.

Now ... what was it that you said?

[joen]

am:

> Sorry but this is way too simplistic

Your reply is way too simplistic.

> if you simply overrun an array bounds you are now writing outside the memory region the OS

Yes.

> and you would crash every single time at the same point.

> It would not be hit and miss.

Not in the case of NIS firewall rules.

Firewall rules vary in length, due to their paths.

So even the _order_ they are entered could cause a different result.

For the same customer!

Let alone different customers with different rules (and paths).

microsoft.com:

"A buffer overrun is one of the most common sources of security risk. A buffer overrun is essentially caused by treating __unchecked, external_ input as trustworthy data."

Overruns in Windows?  Sure.

Vista and Win 7 are said to have 50 Million lines of code.

1) Unchecked 2) external data in AV software?

Inexcusable!

The (unfortunately) brilliant criminals would work hard to figure out how to use that.

[gwm Contributor]

"The (unfortunately) brilliant criminals would work hard to figure out how to use that."

Looks like that statement got an interestingly blank response...

Opps.  Blank response went away.

Reason for edit: Blank response went away.

[AllenM Norton Fighter]

---

joen wrote:

am:

> Sorry but this is way too simplistic

Your reply is way too simplistic.

> if you simply overrun an array bounds you are now writing outside the memory region the OS

Yes.

> and you would crash every single time at the same point.

> It would not be hit and miss.

Not in the case of NIS firewall rules.

Firewall rules vary in length, due to their paths.

So even the _order_ they are entered could cause a different result.

For the same customer!

Let alone different customers with different rules (and paths).

microsoft.com:

"A buffer overrun is one of the most common sources of security risk. A buffer overrun is essentially caused by treating __unchecked, external_ input as trustworthy data."

Overruns in Windows?  Sure.

Vista and Win 7 are said to have 50 Million lines of code.

1) Unchecked 2) external data in AV software?

Inexcusable!

The (unfortunately) brilliant criminals would work hard to figure out how to use that.

---

Exactly, which is why I said it was not that simple.

[joen]

am:

> which is why I said it was not that simple.

Well, _that's_ an oversimplification.  :)

Because there is one thing that is really, really, simple:

UNCHECKED EXTERNAL data caused the firewall failure problem.

Enter too much data and it crashes.

1) Unchecked 2) External

data is NEVER considered trustworthy by any competent programmer.

This is a _huge fail_ for Symantec developers.

We expect that kind of stuff with Windows.

There are 50 MILLION (!) lines of code in Vista and in Win 7.

But in an application (not an entire OS) -- and of all things, an AV application where security is paramount -- that is gross negligence.

You read news articles occasionally where they say that the criminals obtain the well known AV apps and test their malware against the AV apps until their malware "passes the test."

If they are ever successful in getting their "usual" malware on a user's computer (keystroke logger, whatever), I would expect some of them, the higher level ones, to also try to "break" the AV software on that computer to make reentry easier next time.  And as Microsoft says, buffer overruns are a common way.

For Symantec to have allowed this possibility is incompetent.

Too many "yearly" NIS versions (e.g., 2012) for too many years.

Too many update versions (dot, dot releases) during the year.

It doesn't take a coding genius to realize that _many_ of the Microsoft updates are for buffer overrun problems.  Helen Keller could see this coming if she knew that Symantec was not checking external data.  Now all the criminals know.  NIS users are at risk because of this.

There was a real lack of standards and of supervision in the Symantec development group.

[gwm Contributor]

Comments?

[BullSpit]

---

joen wrote:

am:

> which is why I said it was not that simple.

Well, _that's_ an oversimplification.  :)

Because there is one thing that is really, really, simple:

UNCHECKED EXTERNAL data caused the firewall failure problem.

Enter too much data and it crashes.

1) Unchecked 2) External

data is NEVER considered trustworthy by any competent programmer.

This is a _huge fail_ for Symantec developers.

We expect that kind of stuff with Windows.

There are 50 MILLION (!) lines of code in Vista and in Win 7.

But in an application (not an entire OS) -- and of all things, an AV application where security is paramount -- that is gross negligence.

You read news articles occasionally where they say that the criminals obtain the well known AV apps and test their malware against the AV apps until their malware "passes the test."

If they are ever successful in getting their "usual" malware on a user's computer (keystroke logger, whatever), I would expect some of them, the higher level ones, to also try to "break" the AV software on that computer to make reentry easier next time.  And as Microsoft says, buffer overruns are a common way.

For Symantec to have allowed this possibility is incompetent.

Too many "yearly" NIS versions (e.g., 2012) for too many years.

Too many update versions (dot, dot releases) during the year.

It doesn't take a coding genius to realize that _many_ of the Microsoft updates are for buffer overrun problems.  Helen Keller could see this coming if she knew that Symantec was not checking external data.  Now all the criminals know.  NIS users are at risk because of this.

There was a real lack of standards and of supervision in the Symantec development group.

---

Agreed 110%, in addition to the way they handled the problem with us as customers in these forums. They mostly ignored posts and questions, made half hearted attempts with occasional posts to pacify us.

Phone support is good and understanding, however..there is only so much they can suggest and do.

[gwm Contributor]

"Phone support is good and understanding, however..there is only so much they can suggest and do."

So they have stopped telling everyone to uninstall and reinstall?

[BullSpit]

---

gwm wrote:

"Phone support is good and understanding, however..there is only so much they can suggest and do."

So they have stopped telling everyone to uninstall and reinstall?

---

That lasted less than 60 seconds on the first phone call I had with them, when I pointed out what I had posted in the forums.