OT: UK okays warrantless remote hacking of PCs

Sounds like a bunch of government propaganda to me.

Though it probably does work with M$ E-mail products.

With Eudora it's trivial to prevent any executable from functioning, provided you don't have a penchant for opening unknown attachments.

...Jim Thompson

Someone who realises the police are attempting to get into their computer could lead them a merry dance all over the country with misinformation.

Sylvia.

Doh! Nobody ever heard of a hardware firewall?

...Jim Thompson

At one time I liked to think our police state syndrome was being driven forward by a cadre of super clever, motivated, shadowy, high level, civil servants. Many years of detailed watching, revealed this not to be the case.

Instead we sleepwalk to our 1984 nightmare through the careless neglect of spineless, thick, career politicians, coupled with large helpings of incompetance, idleness and gross technical illiteracy amongst those who run our security/police services. The whole then aided and abetted by herds of Euro funded management consultants pushing their targets and measures and initiatives. Southern France looks yet more and more attractive.

I wouldn't be packing my bags for Australia quite yet have you heard of the great Aussie firewall. They are getting just as bad in attempting to censorship the internet. Of course they only have are best intrest at heart.

Or a power switch?

Where's the fun in that?

However, a hardware firewall isn't going to prevent this. Leaving asside movie style attacks involving guessed passwords and the like, hacking exploits faults in software where data downloaded is used in a way unintended by the user. The only way to prevent that is either to write the software properly, or at least safely, (which software engineers have demonstrated a frequent inability to do), or not to download data.

However, engaging in a mass attack, and being satisfied with compromising some computers is one thing. Gaining access to a specific targetted computer is quite another. I suspect those involved in this new policy have been watching too much television.

Sylvia.

Fortuately, so far it's only a proposal for an attempt. As yet, our access in Australia is reasonably unfetterred. There is reasonable hope that the minister involved will eventually get a clue and realise that what he's proposing won't work in practice.

Sylvia.

Likely so ;-)

Several things...

My hardware firewall allows _no_ external access... not software dependent... I pass all of grc.com's tests with flying colors.

Browsing, I use Firefox and allow no scripting of _any_ kind.

Once burned with an E-mail that I thought was a joke from a friend, I blow away any unknown E-mails.

...Jim Thompson

----------------------------------------------------------------------

GRC Port Authority Report created on UTC: 2009-01-07 at 01:20:33

Results from scan of ports: 0-1055

--------------------- 1056 Ports Tested

ALL PORTS tested were found to be: STEALTH.

TruStealth: PASSED - ALL tested ports were STEALTH, - NO unsolicited packets were received, - NO Ping reply (ICMP Echo) was received.

----------------------------------------------------------------------

...Jim Thompson

All to the good, but you're still vulnerable to errors in the way Mozilla, Acrobat (if you use it) etc, process ordinary documents. Things may have improved since the days when Internet Explorer could be subverted just by having a very long URL, but there are sure to be some exploitable errors tucked away.

It doesn't help that software tends to be written in C and C++, which are not safe languages - that is, programming mistakes can cause more than just program failure, but allow corruption of data structures and the execution of data (though belated hardware assistance to prevent the latter is now available, as it already was on Xerox mainframes in the 70s).

Sylvia.

What is this "Internet Explorer" you mention ?:-)

...Jim Thompson

Oh, it's obsolete. You needn't worry about that. I just mentioned it as an example.

Sylvia.

...Jim Thompson

This is a somewhat misguided notion in that *not* using C/C++ just displaces the problem: Instead of looking for exploits of an application directly, you sit around looking for exploits of the virtual machines or system library or "whatever it is" that's executer your "safer language." In general, it's not at all a proven statement that exploiting *that* environment is any more difficult than exploiting an application directly -- particular since "safe language execution environments" tend to be updated more slowly than applications themselves, so any exploits that are found tend to remain effective for longer periods of time. (And think about something like the ever-popular SQL insertion exploit -- doesn't mattter what language you wrote your code in, if someone manages to get you to directly execute their string on your database, they can still do whatever they want, limited only by the permissions of the account you're using.)

I would agree that C/C++ typically it *easier* for novice/inexperienced programmers to write exploitable code, I suppose, but the "solution" of "just don't use them" is essentially the same as saying, "sports cars are dangerous, therefore no one should be allowed to use them" rather than "sports cars are dangerous, they're probably not the best first car for your 16-year-old."

---Joel

Or, designing with discrete components is dangerous, there are so many ways to make a marginal circuit...

dangerous,

Do it all in assembler - nothing easier or safer :-)

The very fact that there's an extra level between the data representing the exploit and the potentially exploitable code make an exploit that much more difficult. In the Java environment at least (I don't know about C#) much of the library code is itself written in Java, meaning that the path from the data controlled by the hacker to the code that could be exploited is tortuous.

But more significant is simply the fact that safe languages don't allow certain types of inherently risky operation, and check other operations for validity before performing them.

Yes, some exploits are language insensitive. Still, at least things like SQL insertion exploits are easier to address with programming standards, and violations of standards are easier to spot (in code reviews that everyone talks about, but few do). Buffer overflow exploits and the like are frequently down to mistakes or naivety, and take detailed code examination to find.

I used to be of the view that we just needed to educate and manage our software engineers better. But it doesn't work. The pool of people capable of becoming competent at the required level is too small. In practice, one has to use engineers of an average ability. The only way to get safe software out of such people is to restrict them to safe languages. It doesn't guarantee safety, but it makes it more likely, and limits the areas where unsafe practices can still exist.

Sylvia.