Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Chrome install blob slips past Debian devs

Here you can discuss every aspect of Debian. Note: not for support requests!
Message
Author
User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 72 times

Re: Chrome install blob slips past Debian devs

#61 Post by stevepusser »

tomazzi wrote:
stevepusser wrote:...
Why do you think it's that difficult to infect HDD firmware? Security researchers don't see anything impossible about malware doing that
...
I didn't said that - I've said, that the attacker needs physical access to victim's infrastructure/hardware to steal the hdd *after* the data is collected.

So, although HDD can be infected / re-programmed just like any other system, it would be plainly stupid to do this - just like breaking open door.

I thought it was obvious...

Regards.

....................
The article said it was necessary to have physical access to the hard drive to recover the data if the target machine was kept off the Net for security reasons. It seems obvious that's how the data has to be recovered in that case. The malware was also able to steal encrypted data--if the user used something like Truecrypt on an uninfected drive, there was absolutely no chance of anyone getting anything off it, no matter if they had the hardware and worked on it for a million years.

However, since a HDD firmware infected machine is essentially "pwned", if it is connected to the Net, nothing prevents the data being extracted through that connection.

The Iranian centrifuge controllers were also kept off the Net to prevent this type of thing, but were still infected with Stuxnet from a flash drive, accidentally or otherwise. But that malware was designed to damage the centrifuges, not extract data.

Re: the moon landings. Nasa also had to send up secret manned missions to deposit the laser reflector, fake LEM lander stages, lunar rovers, footprints, etc., so they could appear in moon satellite images, too. :roll: BTW, please don't tell me you are going by the "flag waves when there's no air" or "there's no stars visible in the photos" type of "problems", are you?

I started to watch the video, and was first convinced by the use of ALL CAPS (SCIENTIFICALLY IMPOSSIBLE), but then the description brought up the hoary old crap about the Van Allen Belts, so forget it: http://www.ibtimes.co.uk/debunking-myth ... ax-1457501

But this is veering way off topic now.
Funny how the Russians never brought up the hoax argument, even when they had the most incentive, isn't it?
MX Linux packager and developer

Randicus
Posts: 2663
Joined: 2011-05-08 09:11
Been thanked: 1 time

Re: Chrome install blob slips past Debian devs

#62 Post by Randicus »

stevepusser wrote:Funny how the Russians never brought up the hoax argument, even when they had the most incentive, isn't it?
If they had, the Americans would have had incentive to expose the Russian hoaxes of orbiting stations and Venus landings. So they kept quiet about each other's hoaxes. :lol:

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Chrome install blob slips past Debian devs

#63 Post by tomazzi »

stevepusser wrote:The article said it was necessary to have physical access to the hard drive to recover the data if the target machine was kept off the Net for security reasons. It seems obvious that's how the data has to be recovered in that case. The malware was also able to steal encrypted data--if the user used something like Truecrypt on an uninfected drive, there was absolutely no chance of anyone getting anything off it, no matter if they had the hardware and worked on it for a million years.

However, since a HDD firmware infected machine is essentially "pwned", if it is connected to the Net, nothing prevents the data being extracted through that connection.
This is just another myth, and yet another brain-hack:
If the system is running, the encryption doesn't protect the data - since the filesystem is mounted, any software can access the data without a problem. So, if You have a physical access to target infrastructure, You dont have to steal the drive - You can just make a copy.

In fact, encryption can protect You only if You would be so stupid to keep critical data on mobile devices like laptops, phones and if You lose them by accident.
But if someone *really* would like to attack You, he can hijack your laptop while You are logged in - f.e. by convincing You that his gun is really loaded - much, much simpler than writting a sophisticated virus for hdd ;)

Regards.
Odi profanum vulgus

somebodyelse
Posts: 231
Joined: 2015-05-24 17:15

Re: Chrome install blob slips past Debian devs

#64 Post by somebodyelse »

America itself does not really exist. It's just an optical illusion. Think about it. There's not a single American who doesn't look like he or she could plausibly come from somewhere else. In fact, I don't even exist and this message is just a product of your own warped mind. Keep taking your medication. Keep taking your medication. Keeeeeppppp taaakkiiinggg yyyyyyoouurrrrr MEEEEEEeedddiCCCCccaaAAttiOONnn.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Chrome install blob slips past Debian devs

#65 Post by tomazzi »

somebodyelse wrote:... Keep taking your medication. Keeeeeppppp taaakkiiinggg yyyyyyoouurrrrr MEEEEEEeedddiCCCCccaaAAttiOONnn.
I can only hope that this guy have survived... maybe there was somebody else who could help him...
Odi profanum vulgus

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Chrome install blob slips past Debian devs

#66 Post by tomazzi »

There are few general rules:

1. If the attacker has a direct access to the hardware, or more generally, to the infrastructure of the target system (a victim), then *ALL* protection systems of any kind are useless.

2. The above extends to a next rule: if the attacker can put a threat on a persons who have a direct access to the infrastructure of the target, then this is in most cases a situation like in point 1.

3. There is a constant conflict of interrests between companies which are "discovering" the threats (viruses) and their clients, which basically boils down to this: Security business just can't exist without viruses/threats.

The above doesn't suggests that today there are no really dangerous viruses, but You should be aware of that fact, because there is a next point to remember:

4. There is a whole class of viruses, which are non-existing in reality - that is, they could probably be implemented, but there are better/simpler/cheaper ways to achieve the same effects. Security guys are rarely taking into account, that the world is 3-dimensional.

5. There was an example of Stuxnet referenced in this topic ("Where did Stuxnet come from"):
Stuxnet is (was) rather a primitive virus, because, besides using some well-known winblows vulnerabilities, its success was based on the fact, that a company who have sold frequency inverters to the victim, have also sold (or just gave) their proprietary protocol specification to the attacker.
This leads to a next conclusion: You have to directly hire someone who knows your business - outsourcing is just a perfect way to get into trouble...

Regards.
Odi profanum vulgus

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 72 times

Re: Chrome install blob slips past Debian devs

#67 Post by stevepusser »

5. There was an example of Stuxnet referenced in this topic ("Where did Stuxnet come from"):
Stuxnet is (was) rather a primitive virus, because, besides using some well-known winblows vulnerabilities, its success was based on the fact, that a company who have sold frequency inverters to the victim, have also sold (or just gave) their proprietary protocol specification to the attacker.
This leads to a next conclusion: You have to directly hire someone who knows your business - outsourcing is just a perfect way to get into trouble...

Regards.
Tomazzi, your statements fly in face of everything I can find about Stuxnet, such as the fact it used an unprecedented four unknown zero-day attacks (!= well-known!), so can you provide evidence that backs that up and why it was "primitive"?

The Siemens controllers were not sold to Iran by the manufacturer, Iran was under an embargo for that type of equipment. Some third party obtained them illegally for them. Please cite evidence to the contrary if you have it. Also you claim Siemens just handed their proprietary code over to the secret developers of Stuxnet. Any citations?
MX Linux packager and developer

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Chrome install blob slips past Debian devs

#68 Post by tomazzi »

Let's make it clear: Stuxnet was a cyber-weapon, created by the US / NATO to destroy military installations in Iran.

Microshit is an US company, and it is known that they're obligated to provide backdoors for "law - enorcement" divisions.
So braking into windows was a trivial part of the task.

The real problem was, that S7 protocol used for communicating with the hardware is very complex and at that time it was completely unknown. But Siemens is also making huge busineses in the US, so what is more probable:
1. CIA have bought Siemens HW and then reverse-engineered the protocol and windows-side libraries (what woulld take a lot of time and money)
2. The've "asked" Siemens to give them specification. Perhaps not even Siemens directly, but a German government, as the they are also in NATO.

Embargo? there's no such thing in reality, especially if the US were interrested in delivering voulnerable HW to Iran.

But even more interesting question is: Why they have chosen Siemens hardware?
The answer is: Because at that time, only Siemens HW ofered a possibility to re-program the hw "on-the-fly", or in other words: You don't need to manually switch between programming and operating modes - it can be done remotely.

Iran could avoid the trouble in a simple way:
Use non-siemens network to connect the devices to a central server, like f.e. modbus, can or whatever else - not profibus, which doesn't allow to block S7 protocol.

Apparently nobody have told them about this - but it was their responsibility to dig into specification instead on relying on external specialists' opinions.

Regards.
Odi profanum vulgus

Randicus
Posts: 2663
Joined: 2011-05-08 09:11
Been thanked: 1 time

Re: Chrome install blob slips past Debian devs

#69 Post by Randicus »

tomazzi wrote:2. The've "asked" Siemens to give them specification. Perhaps not even Siemens directly, but a German government, as the they are also in NATO.
Or the CIA could have stolen it. Espionage is their game after all, even if they are not very good at it.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Chrome install blob slips past Debian devs

#70 Post by tomazzi »

Randicus wrote:...
Or the CIA could have stolen it. Espionage is their game after all, even if they are not very good at it.
Theoretically - yes, but what should be also taken into account, is that all NATO members had the interest in destroying nuclear plant in Iran. So I think, this weapon was created by co-operation within NATO structures.

Regards.
Odi profanum vulgus

Post Reply