Forgot your password?
typodupeerror
Security Windows IT

Malware Targets Shortcut Flaw In Windows, SCADA 214

Posted by timothy
from the thinking-big dept.
tsu doh nimh writes "Anti-virus researchers have discovered a new strain of malicious software that spreads via USB drives and takes advantage of a previously unknown vulnerability in the way Microsoft Windows handles '.lnk' or shortcut files. Belarus-based VirusBlokAda discovered malware that includes rootkit functionality to hide the malware, and the rootkit drivers appear to be digitally signed by Realtek Semiconductor, a legitimate hi-tech company. In a further wrinkle, independent researcher Frank Boldewin found that the complexity and stealth of this malware may be due to the fact that it is targeting SCADA systems, or those designed for controlling large, complex and distributed control networks, such as those used at power and manufacturing plants. Meanwhile, Microsoft says it's investigating claims that this malware exploits a new vulnerability in Windows."
This discussion has been archived. No new comments can be posted.

Malware Targets Shortcut Flaw In Windows, SCADA

Comments Filter:
  • by quanticle (843097) on Thursday July 15, 2010 @05:15PM (#32919602) Homepage

    Seriously, anyone using Windows for SCADA in this day and age has to get their head checked. With the wealth of proprietary and free embedded operating systems available today, the use of Windows in any sort of embedded device should have ended a long time ago.

    • by Anonymous Coward on Thursday July 15, 2010 @05:27PM (#32919726)

      SCADA systems do not run in embedded boards but on full fledged computers. I worked in a company that designed a SCADA system long time ago using iRMX as operating system. The problem with Scada systems have always been its costs that increase when you use special operating systems. The trend now is to run Scada systems in windows machines, but the reliability is not the same.

    • by FooAtWFU (699187) on Thursday July 15, 2010 @05:28PM (#32919738) Homepage
      Embedded device? No, it's the control systems. About 6 years ago I did an internship for a little SCADA company, and wrote something which took their existing customizable form structures (stored in databases, displayed in some Windows form framework that looked almost Win 3.1-ish) and made a version in HTML. The technology looked old even then; I'm sure that there are plenty of Windows control systems sitting around.
    • Re: (Score:3, Insightful)

      by kb1 (1764484)
      The target here is likely the HMI [ge-ip.com] side of things. Many (most?) of the HMIs are Windows based and often built, installed and then ignored. The implementers routinely expect them to be running inside air-gapped networks, so vulnerability patching is not performed and sometimes even actively discouraged. Yes, there are open-source HMI projects [sourceforge.net] available, but try convincing someone to deploy a life-critical system using one of them.
      • by Mousit (646085) on Thursday July 15, 2010 @05:50PM (#32919976)
        Security and vulnerability assessment used to be this poor, but that has undergone significant changes, particularly in this decade. I can't speak for all vendors, but the one we use has security testing, vulnerability assessment, and full patch updates implemented as a standard part of their maintenance contract with their customers.

        They have an internal process to verify all patches on the systems they support their software on (RHEL, SuSE, Windows Server 2003, 2008, Windows XP and Vista, with Windows 7 certification coming) and ensure they do not break the SCADA servers or clients, and they release this information to their customers relatively quickly (we usually are about one month behind, implementing patches that've been vouched safe within about 30 days of the patch release, but this process is faster for zero-day and other such critical things).

        They do not "assume" anything for their customers. However they do strongly encourage air-gap, and frankly so would I. A SCADA system controlling the power grid should never have an Internet connection. It should never need one. If it must have this, you have something seriously wrong with your design.

        Furthermore, I would add that recent (within the last two to three years) updates to CIP [wikipedia.org] and NERC [wikipedia.org] compliance specifications actually require patches to be kept up to date, and also require you to full document the fact that you have patched your servers and workstations. If you have not applied a patch, you must have documentation explaining why (this is why our vendor has their patch vouching program, so you have documentation on why they said don't install something). There are very heavy fines for not implementing this, and can even lead to certification revocation, which means you can't do business.
        • by Svartalf (2997)

          They do not "assume" anything for their customers. However they do strongly encourage air-gap, and frankly so would I. A SCADA system controlling the power grid should never have an Internet connection. It should never need one. If it must have this, you have something seriously wrong with your design.

          Go check out the Smart Grid Interoperability Standard over at NIST sometime...

          They're doing it all the time.

        • by Anonymous Coward on Thursday July 15, 2010 @09:18PM (#32922036)

          Re: CIP (CIP-007 R3), the standard actually requires

          R3. A patch management program
          R3.1. Patches be assessed within 30 days
          R3.2. Document the implementation (usually interpreted as an implementation plan) and install the patches or mitigate

          There is no requirement on the timing of installing the patches in R3.2, only that assessment be completed in 30 days.

          As a result, certain utilities are very legally setting the install plan date for 2013. When they get the opportunity to install, they then update the plan the week they install and document the change. In the interim, they put together a document that shows that IDS, AV, Firewalls, or something else similar mitigates the attack.

          While crazy in the desktop world, most control systems cannot be updated without shutting down generation plants. Transmission has a slightly easier time of it but not much. Shutting down generation during peak periods such as heat waves or blizzards are a worse choice than patching as long as decent security is in place. Major upgrades such as O/S Service Packs and SCADA/DCS upgrades only have an opportunity maybe once a year during planned maintenance shutdowns. This is true regardless of the OS ('nix, Windows, VMS...)

          Yes, certain vendors are very good about updates (Wonderware and similar) and others are very poor. They are all getting better but there is no way I would patch most systema on running coal or gas turbine generation plant. Risks are too high on environment and life safety. A loss of the control system can result in a plant shutdown or scram. A problem control system can put safety at risk because the plant is running and improperly controlling.

          More of a problem is the proprietary hardware, especially on DCS systems. While no direct user interface is present, these systems are never patched, run hidden or semi-proprietary OS's. Worst case I know of is a DCS board that allows remote login with a known unpublished ID/password.

          At least today, virtually every control system is behind an internal firewall and the majority have a decent firewall configuration. However, the value of communicating out of the control system outweighs the risk. Especially when running 15 power plants in a major utility and the power supply/demand balance on the grid is more important than air-gapping. If air-gapped, high quality frequency control at 60 Hz would be near impossible.

          • by Mousit (646085) on Friday July 16, 2010 @08:41AM (#32924926)
            Starting to wander a little off-topic here but I couldn't resist one more answer. :) I wasn't aware of the lack of timing requirement, hmm. Certainly our company didn't interpret it that way, so we're actively implementing patches on the month-behind schedule, and this includes our control systems too. We can do this because every server type (data ack, database, human interface server, etc) we have operates in tandem with an identical twin, in standard failover configuration. So we patch the backup, and initiate a controlled failover to it. Problem? Fail back. Works? Patch the other side now. This is how most every SCADA control system I've worked with has operated, even the old 1970s paired-mainframe-based system we had at the company when I first started here.

            We are a central control center though, the HQ for utility company as a whole, not an individual generation plant. So our system setup may indeed be very different from the individual plants we operate, so I can't speak for how the plants manage their DCS control systems directly. Our major SCADA upgrades though are on a yearly basis, unlike OS patches.

            I see a few people all replied to my air-gap comment, but I'm lazy and don't need to make three replies! ;) I didn't mean to imply it operated in a vaccuum, totally networkless. I merely meant air-gapped away from the Internet specifically. Communications between facilities is indeed vital, it's just that going the Internet route to achieve that is flat out "wrong" and really, I think should be completely banned, by regulation or otherwise.

            We do indeed have inter-facility communications all over the place, to all of our various power plants we operate and control, to all our individual substations, all that stuff. However, it's done via private networks. We have our own microwave communications system licensed throughout the state and probably 90% of our communications to our assets is via this. The rest is through dedicated leased lines. We also communicate realtime with the state's central control authority, and that's done via a private frame relay circuit that THEY actually had installed at our facility (along with their equipment) because they actually require this from all utilities under their authority, to communicate to them. They did it right, basically.
        • by thegarbz (1787294)

          They do not "assume" anything for their customers. However they do strongly encourage air-gap, and frankly so would I. A SCADA system controlling the power grid should never have an Internet connection. It should never need one. If it must have this, you have something seriously wrong with your design.

          It's often not a design problem but a constraints problem. Managers want it cheap, and then want it user friendly. This typically means engineers need to be able to get full diagnostic access to the equipment without moving from their desks, and laying a dedicated fibre to each substation is out of the question. More than likely you're going to end up with a system of independent networks, a control network (for control), an information network (for engineers), and a general network (where the engineer's ac

      • by OzPeter (195038)
        The funny thing is that I work with a lot of GE products. After getting on a first name basis with their tech support people, I know that their programmers are definitely not the sharpest crayons in the box so cracking their software shouldn't be too hard. However they did buy iFix recently and I haven't had a chance to peek the hood of that product so perhaps to might be better than average.
        • Re: (Score:2, Funny)

          by kd5zex (1030436)

          The funny thing is that I work with a lot of GE products.

          Sorry to hear that, if I ever catch up to you in the field I will pick up your bar tab.

      • by Svartalf (2997)

        Considering the reliability of Windows...I'd probably choose to deploy one of the FOSS HMI systems over the commercial ones.

        It doesn't matter if you build a fortress- if you build the same on a foundation of shifting sands.

        • by OzPeter (195038)

          Considering the reliability of Windows...I'd probably choose to deploy one of the FOSS HMI systems over the commercial ones.

          It doesn't matter if you build a fortress- if you build the same on a foundation of shifting sands.

          Can you furnish any links to any decent/competitive FOSS HMIs? Because building a fortress out of mud doesn't appeal to me when I can user armor plating for my fortress. Also I don't think you have a very realistic appreciation of Windows reliability .. (not that I am a fanboi - typing from my Mac) , just that I have worked on lots and lots of commercial systems running windows.

      • by fuzzix (700457)

        Yes, there are open-source HMI projects [sourceforge.net] available, but try convincing someone to deploy a life-critical system using one of them.

        That's the first time I've seen alpha software with a "This may kill you and everyone around you" warning that was literally true.

        It's not a great confidence boost when you're thinking of switching from the commercial solution which I am sure makes plenty of soothing cooing noises about its safety.

    • Re: (Score:3, Informative)

      by mighty7sd (1233176)
      Windows is used all the time for SCADA applications, especially in distributed control systems. SCADA applications aren't just embedded devices, they are typically a Windows server installed on a workstation that is used for the HMI (human-machine interface) used for operators to communicate with the SCADA devices such as PLCs and DCSs. Most operators would not be able to function without Windows so they can check their email on Outlook, surf the web or play solitaire. If you want to use programming and
    • by rubycodez (864176)

      eh, Windows Embedded is an embedded OS

      the cost of the OS is negligible part of system

      • by Alex Belits (437) *

        eh, Windows Embedded is an embedded OS

        Windows Embedded is a Windows OS, not an embedded OS.

    • by Mousit (646085) on Thursday July 15, 2010 @05:38PM (#32919840)
      They're talking about the master/control side of things, the main servers and the operator consoles that people sit at and view indications, and control things. That is where Windows is often run. Embedded devices to this day remain highly proprietary in SCADA systems, though we are seeing more Linux-based embedded devices now.

      The server end though is very often a Windows shop. However, forms of *nix are not uncommon at all either and in fact UNIX types used to be the norm for servers in SCADA, but that's been going away for quite a while now. I'd say it's about 50/50 these days between Windows and *nix. Most of the *nix stuff is now AIX or some flavor of Linux (RHEL being the big one). That's on the server side. The actual consoles where the operators sit are about 90% Windows though, if not higher, and that's most likely where you're going to see this virus come into play in the first place because of some stupid user plugging in an infected USB device.

      Though a proper SCADA shop should have their SCADA system locked down. We certainly do. All USB ports are secured and thumbdrives are not allowed, and disabled from being attached. An operator that can just walk up and stick a USB drive onto a console is a big, big no-no.
      • Re: (Score:2, Informative)

        by Anonymous Coward

        I work in support for Wonderware, which unfortunately, is in 33% of production facilities worldwide. It only runs on Windows, then there's iFix, GE's HMI software, Autosol and Standard Automation products running on windows... A GE DCS may run 'nix, but it reports to and is queried by a WinPC. I think it's probably more 75%/25% in favor of Windows for SCADA systems.

      • by PPH (736903) on Thursday July 15, 2010 @06:57PM (#32920770)

        The actual consoles where the operators sit are about 90% Windows though, if not higher, and that's most likely where you're going to see this virus come into play in the first place because of some stupid user plugging in an infected USB device.

        And then the virus rootkits the control console. It can then issue commands to the SCADA systems that appear to be from legitimate operator input.

        Back when I worked for Boeing, we fought a loosing battle trying to keep Windows systems off the shop floor. In an ideal world, we would have a secure subnet within the company Intranet behind its own firewall to keep the Windows systems from seeing shop equipment. In the real world, lots of the factory equipment was running Windows. Worse yet, some of the people responsible for loading firmware into avionics used Windows laptops to do so. And then they'd take them home at night where the kids would use them to log on to Facebook, or download kewl stuff from unknown sources.

        You can't fire people fast enough to keep Windows out of misson critical areas.

        • by jd (1658) <.imipak. .at. .yahoo.com.> on Thursday July 15, 2010 @08:04PM (#32921464) Homepage Journal

          Ok, I am never flying on a Boeing again. Or any other aircraft. And given that modern computers on cars now use regular ethernet and unsecure protocols (see the papers on successful methods for injecting false commands to the engine and braking systems), I'm going to stay clear of the roads as well. Hell, just get me a Dyson Sphere on some star in some remote galaxy - and a wormhole so I can continue reading Slashdot. Gotta have Slashdot.

      • by omglolbah (731566) on Friday July 16, 2010 @09:13AM (#32925150)

        I recently did installation work at one of the largest gas processing plants in Norway.
        The control system HMI runs on OpenVMS, the controllers are on a redundant token ring network. (good old coax).

        All the control room clients are winxp sp2 with almost no patches. This is required to have the HMI applications work. They also need to be set to 256 colors to get blinking effects (critical in such a system..).

        Will the system be replaced with something newer? Not in a few years. Stopping the plant costs 23 million USD per day just in lost sale/production...

        Now... have there been problems with these vulnerable machines? Nope. Not ever. Control room personell know not to fuck with the clients and behave... They are running a multimillion dollar plant and fucking up is not something you want to do.... You dont mess with the system.. EVER.

        The story describes what I consider an HR issue, not a technical one...

    • The vector is the windows machine that is networked (stupidly)
      to older non windows boxen that do the SCADA work.

      In theory, an attacker could manipulate the SCADA machines
      and cause disruption.

      • Re: (Score:3, Funny)

        by slick7 (1703596)

        The vector is the windows machine that is networked (stupidly) to older non windows boxen that do the SCADA work.

        In theory, an attacker could manipulate the SCADA machines and cause disruption.

        I worked with non-windows SCADA systems. Any windows boxes operated with proprietary software and proprietary communication keys. Without the keys, you have nothing. If any dickwad engineer insisted on windows communications, they deserve exactly what they get and I hope it's a Dell.

    • by MagikSlinger (259969) on Thursday July 15, 2010 @05:40PM (#32919856) Homepage Journal

      Most of the IT your life in the Western world depends on runs on Windows.

      Yes, you are right: it is not suited for the purpose. It says so in the EULA.

      Again, you are right: they have higher down times, increased maintenance due to weekly patching to prevent security problems.

      Uh-huh, I agree. In my experience supporting such systems, they are indeed slower than a good Unix box, harder to administer because you are constantly manually typing things in as opposed to automating them.

      Why are they using them you ask? Because it's all the developers/admins know how to use. They hate using the Unix boxes here at my work, and they keep coming to me to hold their hand doing anything on them. They prefer Windows because everyone has Windows at home or on their desks, and it's a lot easier for my co-workers to understand and use. That's why your quality of life is in the hands of Microsoft.

      BTW, my co-workers are currently plotting to do-UNIXify one our major systems. *groan* They point out how expensive the AIX box is, and how unreliable it is. Um, the same guys who maintain the AIX box are going to maintain the Windows boxes, and if you remember, they did a terrible job keeping them up! It's not AIX that's unreliable -- it's the quality of our admins.

      • by grcumb (781340) on Thursday July 15, 2010 @10:08PM (#32922358) Homepage Journal

        Why are they using them you ask? Because it's all the developers/admins know how to use. They hate using the Unix boxes here at my work, and they keep coming to me to hold their hand doing anything on them. They prefer Windows because everyone has Windows at home or on their desks, and it's a lot easier for my co-workers to understand and use.

        I agree with the first part of that last sentence, and I suspect that if you asked people, they too would claim that Windows is easier to understand and use....

        ... But you'd all be wrong.

        The plain fact is that Windows is simpler in places where simplicity actually hides essential knowledge. Say what you like about Linux/Unix being harder; the fact of the matter is that it's no harder than it should be. The Windows UI, on the other hand, definitely is simpler than it should be.

        Every time someone takes the shortcut and runs a Wizard, the end result is that Microsoft, not the admin/developer, ends up making the majority of technical assumptions, most of which are driven by marketing, rather than actual technical needs.

        The problem, in short, is not that Linux/Unix is too hard. The problem is that Windows pretends to be too easy.

        • by drsmithy (35869)

          Every time someone takes the shortcut and runs a Wizard, the end result is that Microsoft, not the admin/developer, ends up making the majority of technical assumptions, most of which are driven by marketing, rather than actual technical needs.

          For example ?

    • by Thelasko (1196535) on Thursday July 15, 2010 @05:43PM (#32919910) Journal

      Seriously, anyone using Windows for SCADA in this day and age has to get their head checked.

      About 6 years ago I worked as an engineer for a manufacturing company. One day a pop up message appears on my computer. It says something like, "this machine will restart in 30 seconds. Please save all of your work." I saved my work and the machine restarted. A few minutes later, it happened again, and I called IT.

      IT comes out, and looks at my machine. They figure it's some sort of virus, but it turned out to be a worm. The Sasser worm [wikipedia.org] to be exact.

      Machines start rebooting themselves all over the office, and my boss asks the IT manager if this will effect the assembly line PLCs.

      The IT manager gives my boss a very firm, "No!" and goes on to explain how those machines are behind a separate firewall, and can't possibly get the worm.

      Just as he is explaining this, the foreman comes in from the plant and says, "Hey! all of those computers out on the assembly line just rebooted themselves!"

      Our IT director got very red, and went into the server room and unplugged all of the switches. We were one of the few companies using VOIP at the time, and that meant no phone, fax or internet for the whole building.

      Why did we use Windows on the assembly line? I asked that my first day on the job. Corporate determined it was cheaper than running embedded devices.

      The company was shut down for a whole day, costing $20,000 per minute in lost revenue. I can't imagine those embedded devices were that much more expensive.

      As a side note, our IT Manager developed a heart condition at a very young age, and I quit a year later.

      • by bloodhawk (813939) on Thursday July 15, 2010 @06:08PM (#32920198)
        really you are asking the wrong questions. They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too. The question isn't "why were you using windows", vulnerabilities exist in all OS's. The question is "Why the fuck were they not patching known vulnerable systems that are mission critical?" Patch for sasser worm was available well before the worm, secondly "why the fuck if they had a reason to not patch vulnerabilities were they leaving their mission critical devices exposed?".

        What you describe is a massive failure on the part of the IT staff.
        • Re: (Score:3, Insightful)

          by Anonymous Coward

          Sorry buddy, but you got it wrong. This problem doesn't affect Linux based systems. I can plug my usb stick into my computer and I'm not affected by this. Everyone. EVERYONE using microsoft is affected by this. Its not a matter of proper patching or not. This is another newly discovered flaw. It was discovered because microsoft didn't test their software prior to shipping. No other operating systems are affected by this. Only microsoft. And not just 'whats a patch?' systems, but all of them. This

        • Re: (Score:3, Insightful)

          They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too.

          Why do you presume an embedded system would even have an OS?

          The question isn't "why were you using windows", vulnerabilities exist in all OS's. The question is "Why the fuck were they not patching known vulnerable systems that are mission critical?"

          The company was shut down for a whole day, costing $20,000 per minute in lost revenue.

          That probably had something to do with it. Yes, I'm sure yo

        • They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too

          Bullshit ..
        • Re: (Score:3, Insightful)

          by the_womble (580291)

          If they had Linux PCs correctly configured for assembly line work (i.e. only components necessary to that work installed, firewalls on PC as well as network, etc.) how many holes would have been left open by a failure to patch?

          How many would have been left open on any other embedded device OS?

        • Re: (Score:3, Insightful)

          by sjames (1099)

          True enough as far as it goes. Not properly maintaining any system is a problem. The firewall should have actually prevented the spread.

          However, Linux and a number of other OSes (NOT Windows) make it a lot easier to produce a dedicated install with a minimal attack surface (no ports you can't close or services that you can't shut off and uninstall.). The question is why would an industrial control system not be stripped down to essential services. Why was anything there even listening to port 445 or 139?

    • Re: (Score:3, Insightful)

      by Bigjeff5 (1143585)

      Somebody obviously doesn't know what SCADA is used for in this day and age.

      • Somebody obviously doesn't know what SCADA is used for in this day and age.

        Oh come on, that's easy - it's used for swimming underwater and looking at whales and things. Like Jacques Cousteau. Right?

    • by thegarbz (1787294)

      Seriously, anyone using Windows for SCADA in this day and age has to get their head checked.

      While I couldn't agree more, anyone out there running something other than windows for SCADA.... please give me a list of your vendors. You make it sound like we have a grand choice. At our plant we have vibration monitoring systems where the software runs on windows and directly administers the system, and all of our HV switchgear control software runs on windows. About the only system we could buy now that doesn't run on windows is the vibration monitoring system from B&K which runs on ... SCO... I sh

  • Have not .lnk security issues been around since Windows 95? Is this a new one?
  • by MrEricSir (398214) on Thursday July 15, 2010 @05:20PM (#32919650) Homepage

    ...for taking shortcuts.

  • Realtek (Score:3, Insightful)

    by StikyPad (445176) on Thursday July 15, 2010 @05:21PM (#32919660) Homepage

    and the rootkit drivers appear to be digitally signed by Realtek Semiconductor, a legitimate hi-tech company.

    For very loose values of "legitimate." Realtek is the Yugo of hi-tech.

    • by nschubach (922175)

      I have a few Realtek NICs (8139) that are among the most reliable and simple devices to install.

      Maybe I just got lucky, but I have a few PCI Realtek NIC that I've moved from PC to PC doing upgrades and NEVER had a problem with it working on any Operating system I've ever installed.

      The damn thing just works, flawlessly. Is that so bad?

      • by KiloByte (825081)

        Once upon a time, Realtek's cards made up >80% of all network cards people around here used.

        In the times of 10Mbps BNC and early 10baseT, typical prices were like:
        * PLANET's NE2000 "compatible": 50zl
        * Realtek's 8029: 60zl
        * 3Com's 3c5x9: 700zl (yeah, it's not a typo -- over an order of magnitude more)

        The latter two were damn reliable, while junk cards worked only on a good day, hardly ever managed to talk to cards made by other manufacturers, worked or not based on the room they were in, and even when by

        • It's only after every single motherboard started to include on-board networking that Realtek stopped being relevant.

          Not sure if you realize it or not, but 90%+ of all motherboard onboard NICs, are made by Realtek.

          Don't believe me? Check your lspci / Device Manager.

      • Re:Realtek (Score:5, Interesting)

        by StikyPad (445176) on Thursday July 15, 2010 @06:02PM (#32920136) Homepage

        The 8139 is one of the shittiest NICs ever created. It personifies the Realtek ethos of bottom-of-the-barrel, "get it to sort-of work and ship it" engineering. The fact that it works on "any operating system you've ever installed" is a testament not to the virtues of Realtek, but the skill and dedication of a few people who undertook the monumental task of creating drivers. Don't get me wrong, I'm glad I have $5 surround sound on my motherboard, but I still wouldn't piss on Realtek to put out a fire.

        * Supports several extremely cheap PCI 10/100 adapters based on
              40 * the RealTek chipset. Datasheets can be obtained from
              41 * www.realtek.com.tw.
              42 *
              43 * Written by Bill Paul
              44 * Electrical Engineering Department
              45 * Columbia University, New York City
              46 */
              47 /*
              48 * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
              49 * probably the worst PCI ethernet controller ever made, with the possible
              50 * exception of the FEAST chip made by SMC. The 8139 supports bus-master
              51 * DMA, but it has a terrible interface that nullifies any performance
              52 * gains that bus-master DMA usually offers.
              53 *
              54 * For transmission, the chip offers a series of four TX descriptor
              55 * registers. Each transmit frame must be in a contiguous buffer, aligned
              56 * on a longword (32-bit) boundary. This means we almost always have to
              57 * do mbuf copies in order to transmit a frame, except in the unlikely
              58 * case where a) the packet fits into a single mbuf, and b) the packet
              59 * is 32-bit aligned within the mbuf's data area. The presence of only
              60 * four descriptor registers means that we can never have more than four
              61 * packets queued for transmission at any one time.
              62 *
              63 * Reception is not much better. The driver has to allocate a single large
              64 * buffer area (up to 64K in size) into which the chip will DMA received
              65 * frames. Because we don't know where within this region received packets
              66 * will begin or end, we have no choice but to copy data from the buffer
              67 * area into mbufs in order to pass the packets up to the higher protocol
              68 * levels.
              69 *
              70 * It's impossible given this rotten design to really achieve decent
              71 * performance at 100Mbps, unless you happen to have a 400Mhz PII or
              72 * some equally overmuscled CPU to drive it.
              73 *
              74 * On the bright side, the 8139 does have a built-in PHY, although
              75 * rather than using an MDIO serial interface like most other NICs, the
              76 * PHY registers are directly accessible through the 8139's register
              77 * space. The 8139 supports autonegotiation, as well as a 64-bit multicast
              78 * filter.
              79 *
              80 * The 8129 chip is an older version of the 8139 that uses an external PHY
              81 * chip. The 8129 has a serial MDIO interface for accessing the MII where
              82 * the 8139 lets you directly access the on-board PHY registers. We need
              83 * to select which interface to use depending on the chip type.
              84 */

        http://fxr.watson.org/fxr/source/pci/if_rl.c [watson.org]

    • Re:Realtek (Score:5, Insightful)

      by fuzzyfuzzyfungus (1223518) on Thursday July 15, 2010 @05:33PM (#32919790) Journal
      They may be pretty chintzy; but they are downright ubiquitous. Things are going to get comedic if every Realtek-equipped PC that also gets Windows updates suddenly starts throwing "unsigned driver" warnings because Microsoft revokes their trust of the Realtek signing key(which they might chicken out of; but they really should do if there are signed rootkit drivers floating around)...
    • by Nimey (114278)

      The Crab's stuff is better than it used to be. Their NICs are pretty good quality; not quite up to Intel standard, but good for what you pay. Sound is merely OK quality, but reliable.

  • I thought they would barely manage to point and click, and the keyboard were a mistery to them, just like the whole UI is designed to train them to behave...
    I doubt more than 5% of the (l)users actually know what a shortcut is, considering how they are intentionally hidden away as deep as possible, or even completely removed.
    (I’m not hating Windows specifically. “modern” [aka. “dumbed down beyond being usable”] KDE/Gnome and OSX UIs often are not much better nowadays. :/ But th

    • by c6gunner (950153)

      I doubt more than 5% of the (l)users actually know what a shortcut is, considering how they are intentionally hidden away as deep as possible, or even completely removed.

      Yeah, that's right, the start menu and desktop are intentionally hidden away or completely removed. The screen just shows a pretty picture, which does nothing when you click on it.

      • Wow. You did manage the single two things left. ^^

        How about the shortcut to:
        - lock the system
        - search a file
        - run something
        - browse the file system
        - show the desktop
        - switch between the task bar, the desktop and your application
        - print just the window
        - all the Alt-something shortcuts for the menus
        - close a document
        - close a application
        - etc
        they all exist. They all make work faster. How many do you think the average user knows? Hm? One?

        And how about
        - the directory structure of the file system browser resembl

        • by c6gunner (950153)

          That was a very nice rant, which had dick all to do with windows shortcuts. Unfortunately, you seem to have confused keyboard shortcuts with file shortcuts (also known as "links"), while simultaneously bitching about every other way that every OS in existence has apparently failed to please you. Boo fucking hoo.

          On the other hand, you DO sound amazingly like one of those crazy talk-show hosts, such as Bill O'Reilley or Keith Olbermann. Do you have your own TV or YouTube show? I'd love to subscribe.

        • by drsmithy (35869)

          And hey, OSX actually presents this "simplicity" (actually lack of freedom) as a bullet point in the feature list.

          That's right folks - when it's easy, it's because THE MAN is keeping you down. The truly free know that every breathe is a struggle, and they're THANKFUL for it.

    • Our users are safe. They use Outlook for all their shortcuts.

      <rimshot>
  • Solution (Score:5, Funny)

    by mark72005 (1233572) on Thursday July 15, 2010 @05:52PM (#32920006)
    They should avoid holding the USB drive that way.
  • Power stations (including nuke ones) use SCADA for control systems. Not the kind of stuff you really want to be infected with malware. Sure, the odds of anything really nasty happening is slim (it does happen though - the main Japanese nuke power station has accidentally vented radioactive material into the air in the not-too-distant past). The most likely event is a shutdown, followed by a blackout of a region. If there's a cascading effect, it might even take out a whole State until they reload the comput

    • Re: (Score:3, Interesting)

      by Svartalf (2997)

      The high cost of real-time and "trusted" Operating Systems (which would have been far better choices) is also responsible.

      The reason they're "expensive" is because of the efforts to try to ensure secure and reliable operation in the face of attackers. Don't be laying the blame at the feet of the OSes- lay it at the feet of the cheap people that sought to maximize profits while ignoring the risks involved with the choices they were making.

      • Re: (Score:3, Interesting)

        by jd (1658)

        Oy! Dark Elves aren't supposed to make sensible comments.

        Anyways, the way secure OS kernels are generally written is to move the critical functions into a "security kernel". Only that security kernel needs to be proven correct. Flaws in the rest of the OS cannot cause vulnerabilities. Well, in theory. But once that security kernel is written, then the expensive part of the development is done. It's proven complete and correct, so you should almost never have to touch the security kernel again. That componen

  • And how... (Score:4, Insightful)

    by Securityemo (1407943) on Thursday July 15, 2010 @06:29PM (#32920442) Journal
    This is awesome. A major 0day? They stole the signing key from realtek? And it's not like you can instantly invalidate those keys without major hassle. I wonder how many other such "cert" keys have been stolen over they years.
    Besides that, why code an interface specifically for Siemens SCADA? One question you'd have to ask is, does that system have marketshare for the control systems of any specific type of thing, or is it generally just popular in industrial automation? I can't find anything specific online, besides advertising writeups about factory control.
    • Re: (Score:3, Interesting)

      by PPH (736903)

      Besides that, why code an interface specifically for Siemens SCADA?

      Because 1) it has a large market share, 2) it may have been the first brand that the virus writers managed to reverse engineer. Stay tuned for versions that work with Allen Bradley and others.

      SCADA systems have traditionally been highly proprietary, depending on obfuscation for security. Some of the newer systems have learned fom the open source movement. "You may have our protocols, even our source. But you'll get nowhere without the key." But they don't have major market share yet, And that's not the way

      • That's interesting to know. How complicated are the protocols? Would you have to actually get a hold of hardware components with embedded software on the "receiving" side to get a complete set for reverse-engineering, if you didn't want to reverse the protocol from the client code? ...
        Realtek has factories in China, and chinese "spies" would certainly be able to prochure whatever they needed from Chinese factories if I've understood the situation correctly.
  • See this link for what can happen to your SCADA systems - total distruction [scada1.com]
  • by Que_Ball (44131) on Thursday July 15, 2010 @06:56PM (#32920758)

    So looking at some of the linked info it appears that this is targeting a Siemens SIMATIC WinCC Database. It appears that the database uses a hardcoded username and password combination that end users are told not to change. I found some forum postings from people who made the mistake of changing the password only to have the software fail.

    Server=.\WinCC;uid=WinCCConnect;pwd=2WSXcder (+1 for what appears to be a reasonably random looking password, -1 for being short, -1 for not including symbols, -100 for hardcoding it into the app and forcing all users to have the same exploitable entry point into their embedded database that this worm can use to read and inject code into the database)
    https://www.automation.siemens.com/forum/guests/PostShow.aspx?PostID=16127&Language=en&PageIndex=2 [siemens.com]

    Product being targeted:
    http://www.automation.siemens.com/w2/automation-technology-distributed-control-system-simatic-pcs-7-1075.htm [siemens.com]

    Seems pretty clear that this was a targeted attack. (Launched by Competitor, former employee, etc)

    • by fuzzyfuzzyfungus (1223518) on Thursday July 15, 2010 @09:39PM (#32922198) Journal
      Wow. That is some incredible quality there.

      I'm assuming that this product is of the "Well, it sucks ass; but at least it was incredibly expensive..." school of enterprise software design?
    • by ymgve (457563)

      Server=.\WinCC;uid=WinCCConnect;pwd=2WSXcder (+1 for what appears to be a reasonably random looking password

      Only random looking. Glance down at your keyboard as you type in that password.

      • by thijsh (910751)
        Basically just a crooked QWERTY password!!! :-D
        I was all 'yeah, it can happen to any Windows system...' until I read about this hardcoded shit password, they had it coming! It has probably been leaked to a competitor by some anonymous employee who was ignored too many times when pointing out security issues..
  • I used to work for a SCADA company our practice was to try to encourage (and was usually successful) to get the customer to cut the ties between the outside network and SCADA control system. Most system designs would often include an extra box with an extra link for an operator to access corporate email, internet, etc

    That wouldn't preclude someone slapping something on a USB and taking it over..but why?

Hacking's just another word for nothing left to kludge.

Working...