Bugs and security vulns are almost unavoidable - but some are due to gross negligence. Gross negligence should always be open to litigation. To follow on from Microsoft's analogy, if a door manufacturer was grossly negligent (let's assume that the door includes the lock and hinges - when this isn't normally teh case), and sold a high security door system, but had accidentally keyed all the doors to a single grand-master key. Then if you were burgled because a burglar happened to find out about this grandmaster key, then potentially you have a claim.
I don't see why it shouldn't be too different in software development. A software vendor needs to bear some responsibilty for good programming practice.
Bad software is everywhere; some is so bad, that it does border on grossly negligent.
As an example, I recently reverse engineered an "electronic patient record" system that was installed at a local hospital. This had a number of interesting design features: 1. Password security was via encryption rather than hashing. The encryption was a home-brew modified Vigenere cipher. 2. The database connection string was stored in the clear in a conf file, stored in the user's home directory. Interesting the database connection used the "sa" user. 3. Presumably for performance reasons, certain database tables (notably "users") would be cached in plaintext to the user's home directory. This way, an SQL join could be avoided, and the joins could be done client side. 4. The software ran an auto-updater that would automatically connect to a specified web site and download and run patches as admin - without any kind of signature verification. 5. All SQL queries were dynamically generated strings - no parameters, prepared statements or stored procedure. Not every user input was properly escaped. Entry of a patient name with an apostrophe in it, would cause very peculiar behavior. In the end, regular memos had to go round to staff telling them under no circumstances to use apostrophes in patient names, and to avoid, wherever possible the use of apostrophes in the plain text entries.
This is by no means all the security problems this software had, never mind the bugs e.g. a race condition when synchronising with a second application which would result in the two components opening different patient's charts.
Amazingly, there weren't any security breaches or significant medical errors as a result of this software - but I can't really conclude that this software production was anything other than grossly negligent.
The lead is likely very effective at reducing recorded exposure - probably cutting it by 75-90%. Most of the radiation in a typical fission product incident is beta radiation, which will be substantially attenuated by 1 mm of lead (the beta particles won't get through, but probably 1-2% of their energy may get through as bremmstrahlung X-rays). Gamma rays, will also be attenuated but only by a few % (high energy direct photons won't be significantly affected, but photons scattered from concrete, etc. will be of much lower energy, so will tend to be heavily attenuated).
There are plenty of radiation suits that offer 0.1 or 0.2 mm lead equivalent protection (they don't usually contain lead for environmental reasons, bismuth is usually used instead). These are quite useful for protection against beta energy, even if they do nothing for gamma. However, the sheer weight of even a 0.2 mm lead suit makes it only barely practical (though I understand the US military have bought a lot of them).
However, lead boots are a sensible precaution - most of the radiation in a Fukushima type incident is in the form of water soluble or suspended particles, which pool on the floor in puddles. Severe radiation injury to the feet from beta emitters is possible - 1mm lead equivalent rubber boots are tolerable to wear, and would offer substantial protection to the feet.
He did should very loudly about an intentional backdoor in the windows metafile image handler, which would start executing native code when a callback command was included in the script. He made a large number of spurious arguments as to why this was clearly intentional, as the vuln could only be triggered in very exceptional circumstances.
He was completely wrong about almost everything he said. The vuln was trivial to trigger, except when it was the last instruction in the script (which was the only way Gibson was testing). From the fact that he had great difficulty triggering it, requiring multiple parameters to be set to nonsense values, he concluded that this was clearly a deliberate backdoor.
It later came out from a number of MS insiders (incl. Mark Russinovich) that metafiles were a feature of Win 3, and were intended to be fully-trusted OS components (for rapid image drawing, and therefore had privileged access to a variety of internal system calls - notably the ability to set callbacks). The functionality was greatly increased in Win95 and later, with the original x86 hand-written assembly being ported directly, rather than rewritten. In the mists of time, the assumption of full-trust got lost.
In most areas where condos exist, the commercial ISPs will offer adequate DSL or cable services. This way, individual residents can make a decision about what service they want, and purchase the DSL or cable service that suits them.
Simply lay down a few ground rules to condo residents: No externally mounted dishes, No new visible cabling in communal areas, etc.
The condo assoc, may be willing to assist in installing ducting - this way, residents can chose fiber, cable, DSL, etc., and it can all go through existing ducting which only needs to be paid for once and won't require new building work when new technology X comes along in 5 years time). In fact, probably the most sensible thing to for a CA to do would be to install some cable ducts running from the basement cable entry point along corridors to individual apartments. That way when a resident wants new cabling installed, all the contractor has to do is install the cable into the ducts and it's job done. FTTP providers may even wish to fill up your ducts with sub-ducts. This is the maximum level of involvement that I would suggest. By having the CA do the duct work, you keep control of quality of workmanship. A particular problem with high-rise blocks is fire codes. Often, they require any hole in an individual apartment to be fully firestopped. This is not a job you should trust to individual network operators, and their low-cost installers. Make a decision to install building wide ducting, and get it properly installed, firestopped and certified.
Running an ISP is a difficult business, both on technical and customer service grounds. The network design is difficult and needs to be done by an expert. Further, how much time are you budgeting for fielding technical support queries, billing, DMCA requests, etc. If you get a DMCA request, which identifies your IP (or one of your IPs), how are you going to forward it to the alleged offender (You've got DHCP server logs, haven't you?) . If you can't forward it, because you don't know, will you face criminal penalties yourself? You might not now, but laws change (in the UK, if you resell an internet service, and a criminal act is committed via it, and you don't keep information allowing you to link an identifiable person with the particular communication, YOU are personally liable).
Similarly, if running a communal ISP, how do the costs work if residents choose not to participate? HSPA+ and LTE dongles are on the market and, where I live, they are killing wired internet and WiFi. I now know many people whose only internet access is a smartphone/tablet with 3G - and that's all they use at home.
Yes, you may be able to get a better service for less money if all 80 residents participate. But what if only 40 participate? What happens when you start getting into legal problems (whether legitimate or not)?
FPGAs commonly protect user-code with encryption. An encryption engine is included in the silicon to which the user has limited access to crypto=keys with which to encrypt the code that is installed in ROM/Flash.
A number of attacks are known against microcontrollers/FPGAs that secure code with encryption - notably differential power analysis (DPA) which works by connecting a current probe to the chip, and collecting measurememnts of energy consumption as the device performs an authentication operation. By carefully, measuring power traces over thousands of authentication operations, statistical analysis can reveal clues about the internal secret keys; potentially allowing recovery of the key within useful periods of times (minutes to hours).
These secure FPGAs contain a heavily obfuscated hardware crypto-engine, with lots of techniques to obstruct DPA (deliberately unstable clocks, heavy on-chip RC power filtering, random delay stages in the pipeline, multiple "dummy" circuits so that an operation which would normally require fewer transistors than an alternative, has its transistor count increased, etc.). The idea being that these countermeasures reduce the DPA signal and increase the amount of noise, making recovery of useful statistics impractical. In their papers, this group admit that the PA3 FPGAs are completely impervious to DPA, with no statistical clues obtained even after weeks of testing.
This group have developed a new technique which they call PEA which is a much more sensitive technique. It involves extracting the FPGA die, and mapping the circuits on it - e.g. using high-resolution infra-red thermography during device operation to identify "interesting" parts of the die by heat production under certain tasks - e.g. caches, crypto pipelines, etc. Having identified interesting areas of the die, an infra-red microscope with photon counter is focused on the relevant circuit area. As it happens, transistors glow when switched, emitting approx 0.001 photons per switching operation. The signal from the photon counter is therefore analogous to the DPA signal, but with a much, much stronger signal-to-noise ratio, allowing statistical analysis with far fewer tries. The group claim the ability to extract the keys from such a secure FPGA in a few minutes of probing with authentication requests.
The researchers claim to have found the backdoor, by fuzzing the debug/programming interface, and finding an undocumented command that appeared to trigger a cryptographic authentication. By using their PEA technique against this command, they were able to extract the authentication key, and were able to open the backdoor, finding they were able to directly manipulate protected parameters of the chip.
You assume that NTLMv2 or kerberos are the default authentication methods. The workstations ran, and still run to this day, XP SP1 as that is the most recent OS supported by the vendor of the software.
XP SP1 uses NTLMv1 as the default authentication method which does not make use of the time during authentication.
This is often a case of poor administration, perhaps more frequently than poor design.
For example, I was recently tasked with reviewing the performance of several hospitals in the diagnosis and treatment of stroke. Under national guidelines (UK) a patient with suspected stroke must have had a CT scan within 30 minutes of arrival at hospital, with blood-thinning treatment administered within 60 minutes (if appropriate).
The problem was that the times on the CT scanners were discrepant by +/- 45 minutes from true time - so the images were tagged with the incorrect time. Further, the CT viewing workstations had times up to 2 hours discrepant. The CT scanners were Windows or Gentoo depending on the manufacturer's preference. Similarly, the CT workstations were windows, and were all bound to the hospital domain.
The time discrepancies made my assessment very difficult - and I had to correct for each individual scanner, and assume that the clocks hadn't drifted over the 6 month period of the audit.
I also found several safety issues because of this - e.g. if it was 1am, and a patient had a CT scan, some workstations would be 2 hours slow, so would read 11 pm on the previous day. These workstations would refuse to load the CT scan because the files were filtered by "WHERE [StudyTime] NOW".
I raised a support issue with the workstation vendor who simply said "These are windows workstations. You should ensure that they are appropriately bound to your domain, and configured to sync with your time server or domain controller". So I called IT to configure this, "No way. These are medical devices, we can't change the configuration - and anyway, what will happen if the clock is fast, and the sync pushes the clock back, so that there are 2 occurrences on the same time. That would cause chaos. Even if the manufacturer supports it, there's no way we'll set it up". Of course, their concern doesn't actually exist, because most time sync algorithms (even on Windows) are clever enough to avoid "double time".
There was similar obstruction with the CT scanners. The vendors simply said - we support and encourage synchronisation with a time server. IT or the radiology administrators simply stonewalled the ideas. They refused even to correct the clocks on teh scanners - so the clocks are still wrong to this day (even more so, due to accumulated drift).
Of course, even if the time can be set right - there is disagreement as to how daylight-saving is managed. Some equipment, esp. older embedded kit isn't daylight-saving aware. Do you set it to Summer time or winter time? In most hospitals I've been in, it's been an inconsistent mixture - often with lots of clock drift added, so you can't actually be sure.
One of the difficulties is that priorities in government sector procurement are often biased in favour of the senior management and doing what is seen to be good politically, rather than usability or manageability.
The difficulty with the govt tender process is that some vendors are unfamiliar with it and don't give the best answers to the questions asked in the initial tender documents.
E.g. I've just been involved with the procurement of a PACS system (digital X-ray archive), and a lot of the vendors simply scored 0 on a large number of points when they returned their responses to the original specification document.
For example (these are not verbatim examples, but fictional examples which I believe accurately depict the problem): Tender question: Describe how the software ensures compliance with the Data Protection Act (DPA).
Typical bad answer: The software is compliant with the DPA. (This is a totally meaningless answer - as a result the vendor scores 0 on this specification point).
Typical good answer: The software has features that assist the hospital in meeting the following aspects of legislation: Control of access, control of retention, Prevention of disclosure and assisting staff in preparation of subject access requests. Control of access: The software provides for password, certificate, hardware token or active directory authentication. There is a role based permissions system with arbitrary complexity - for example, a nurse's login could be restricted to access of patients only on her ward. Permissions can be controlled on a role or user level, and can provide access control on any image, case-record metadata (including custom fields) or metadata available from a connected information system.
Control of retention: Data can be destroyed automatically when no-longer needed. The period can be configured by the local adminstrator according to local policy. A rules-engine is included which permits granualar control of retention based on, for example, patient age (children's examinations can be kept until adulthood, instead of on a data age), type of exmaination (e.g. research studies may need longer retention), manual flags, any image metadata, or metadata from a connected information system.
Prevention of disclosure: All data stores are encrypted with 256-bit AES. Data transmission over the LAN, or public networks, are encrypted using TLS 1.1 with 256-bit AES. If data caching on client machines is permitted by the administrator and local policy, the data is encrypted using 256-bit AES. All system accesses are logged in an audit-trail. Powerful analysis tools, including a rules-engine, are provided to allow investigation of suspected abuse. If the system administrator permits images to be saved to teaching files/powerpoint documents/etc., image metadata containing patient identifiers will be removed automatically. If the images contain patient identifiers in the pixel data, then the images will be redacted automatically (subject to the availability of appropriate metadata in the original image files).
Subject access: The system can provide a full subject access report for both patients and users (staff). The report will include all data, including audit trails, together with summary (the staff report will have patient data redacted automatically), and can be exported to optical disc or hard drive in a single operation.
With an answer like that, it has to score 10/10.
The problem is that most of the software vendors are not very good at understanding the questions - particularly, where they relate to legislation. The big winners here tend to be the big contractors, often infamous in the national press for supply of poor quality solutions. They "get" what the questions are asking, so score big - and this often makes up for less-than-stellar performance in the technical and usability sections of the scoring.
They just put an old OS on. At the hospital I work at, there are a number of critical applications (like parts of electronic patient records, and other custom made apps) which only work on IE6.
That means the brand new workstations we took delivery of last month (dual quad core Xeons, 4 GB RAM, Fire GL Pro cards) have all been loaded with XP 32-bit SP1, in order to get IE6 and avoid some features of SP2 which break a number of other apps.
To be honest, it's a miracle that they're stable, as I can't believe the drivers for the graphics cards, etc. are fully supported on this OS.
It's true that SMS "just works" now. But that is only a recent development.
5 or 6 years ago - SMS across a national boundary was a lottery. It might work, it might not, and you'd have no way of knowing when, or even if, your message was delivered. This was particularly the case with the US, where SMS was particularly unreliable.
Even SMS between individual networks within a country wasn't always as reliable as you might have expected.
The type of lamp you want exists, and is very widely used commercially for shop lighting. It's called ceramic metal halide. A 20W lamp produces about 2200 lumens from a very compact (3-4mm) point source. When used with a reflector, they make excellent accent lighting, and there are plenty of commercial products that install them on tracks, etc. They have excellent color rendering (far better than the best LEDs and fluorescent) and are available in a variety of color temperatures. The lifetime is also long - typically 15,000-20,000 hours. They are even dimmable, although the dimming range is limited (and while the lamps will dim, and there are color shifts).
The efficiency of ceramic metal halide is unmatched by any other commercially available technology (except for sodium lighting).
The problem is the price - which is enormous (partly as these are targeted at commercial use, where replacement labor cost and energy costs/cooling costs dominate; but also because it is inherently an expensive technology), not just in terms of the bulb cost, but the ballast to power it. There are other problems too, such as a long warm up time (60 seconds) the first 15-20 seconds of which result in virtually no light output; and a very long cool down time (5-10 minutes) during which time the lamp cannot be restarted.
Nevertheless, CMH is pretty much the leading lighting technology in high-end retail, for the above reasons. I picked up an old shop CMH unit off ebay, and have it at home - and it is stunning. Brilliant brightness, tightly focused beam, very high color quality, flicker-free. Thankfully, replacement bulbs are available very cheap off ebay - there's no way I'd pay the $50+ retail for the bulbs.
Quite. A lot of our "medical devices" are actually software programs running on PCs. Many of them require a specific environment to run.
I can think of one package that will only run on: Windows XP32-bit (No service pack) and Java 1.4. It simply won't run on anything more recent (no idea why), and the developer of this (very expensive) package has gone bust, and the product is no-longer supported (but the finance department budgeted on a 10 year usable life-span, so it's not getting replaced for 10 years following installation).
I've no idea of the total number of vulnerabilities on the combination of unpatched XP and Java 1.4- but I suspect, the number is substantial.
Medical devices don't just include things like implantable equipment (such as implantable defibrillators, pacemakers, pumps, etc.) but analysis equipment, and more recently computer software running on regular PCs (such as electronic patient records, order management systems, digital X-ray system/picture archiving and communications systems), etc.
Implantable devices have been in the public eye recently because they don't use very secure protocols. Typically, the wireless controller transmits a command prefixed by the serial-number of the implanted device. The device then ignores commands which are not prefixed by the appropriate serial number. This is OK for preventing programming the wrong device in a clinic situation, but a hacker could easily perform a replay type attack to cause the device to administer an inappropriate treatment or dose. One reason that manufacturers have given for this is an extremely limited power budget - strong cryptography simply burns too much energy for a device which cannot be recharged.
One problem that has concerned me as a user of medical software is just how poor the security is on a surprising number of products. One product that I use at the moment is part of an electronic patient record system. This system doesn't quite store user passwords as cleartext in the database. However, instead, it encrypts them with a Vigenere cipher (using the username as key). However, because of excess load on the database server, the software very concienciously caches the entire "Users" table as a CSV file on the client computer. Yes, when I discovered the file, it didn't take long for the Mk I eyeball and my recollection of my password history (which was also documented in great detail in encrypted format) to determine the cipher and what was being used as the key. This was subsequently confirmed by running the binary through a decompiler, which revealed a number of other wonders such as potential SQL injection vulns. Of course, none of that really mattered - there was an interesting file called "C:\epr.ini" which contained such lines as: [ClientDatabaseConnectionString] Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=EPRORA)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)));User Id=SYSTEM;Password=pyramid1;
However, even leaving aside such extraordinarily bad software from small IT contractors, even the big-boys in the healthcare arena seem to have problems with basic testing, and anything even vaguely corner-case will often result in strange behavior - and that's just routine use, I can imagine all sorts of vulnerabilities appearing if these software packages were subjected to serious attack.
In fact, even in healthcare systems which are supposed to be paradigms of good design, implementation is often very poor. Professor Ross Anderson in his book "Security Engineering" mentions a national security system used in the UK for securing health records, where an individual user's smartcard contains an individual certificate and permitted user roles, which interact with the software to release the appropriate records. On the face of it, an excellent system - and one that Anderson mentions as an example in his book. For a user, however, the implementation is a disaster area; it's unreliable (depending on a national authentication server - local caching was broken in the first 11 6-monthly releases) and vulnerable to DOS attacks. Authentication with the national server was hopelessly slow (taking up to 5 minutes) so was useless for doctors in a busy environment such as the ER. The Roles are administered on a national level, with no way to override errors in role allocation before the next 6-month release (e.g. the first few releases did not permit doctors to change the brightness/contrast of an X-ray that they were examining - this function was restricted to sysadmins only) - the user role administrators acknowledged that this was a serious problem, but refused to push out a hotfix, instead it had to wait for the next role release. In reality, the nurse in A
It's not the wiring per se but power quality. Voltage fluctuations where the mains voltage goes out of spec (brownouts and overvoltage) are a major cause of problems. Electronic power supplies are often heavily stressed by under-voltage conditions, because they increase their current consumption to compensate, resulting in increased heat production in the power supply. Overvoltage can result in internal components being overstressed.
The other problem is high-voltage "spikes" - ultra-short duration (a few microseconds) increases in supply voltage (to 1-2 kV), due to large electric motors (e.g. HVAC compressors) being switched on or off, nearby lightning strikes, etc. These voltage surges won't affect incandescent light bulbs, but will destroy electronic power supplies instantly. Things like PC PSUs are fitted with surge protectors internally, to protect them from this type of spike. Good quality CFLs and electronic lighting ballasts also contain decent surge protection. However, garbage grade CFLs, often leave out these components to save $.10.
The other problem with CFLs is that they are intolerant to heat. This means that care is needed over the type of fitting. CFLs are not suitable for use in enclosed fittings - they must be open to the air, otherwise you don't get any air circulation and the lamps overheat. While incandescent lamps are frequently-used "base-up", CFLs risk overheating the electronics in the base, when used in this orientation. CFLs are best used "base-down".
If you genuinely think there is an electrical problem at your home - then you want a power quality check. This would normally involve installing a data-logger in your house for a week, to see if there are any significant problems with voltages, spikes, waveforms, etc.
I've taken apart a number of Philips' premium lighting products (both top-end CFLs and also electronic ballasts for fluorescent and high-intensity discharge lamps).
I was pretty surprised to see absolutely nothing but the best components. All the capacitors were either high quality metalized film, ceramic or premium ultra-long-life high-temperature Japanese Al electrolytic from a tier 1 manufacturer.
Similarly, the active components were heavily over-specified 100% avalanche rated rugged MOSFETs, with high quality protection (diode clamps and current limiting resistors) on the gate drives.
While cheap Chinese CFLs often use garbage grade components - I was pretty surprised at the quality of the commercial lighting products - but then I suppose that's why these units command such high prices.
I've seen one landfill with a couple of 1 MW generators selling electricity to the grid. Another, sells the gas to the nearby village for use for heating the community centre.
Most recently, I've seen one where the landfill gas is captured and used to fuel the garbage trucks. (Diesel/CNG dual fuel).
Some of it is. TB requires prolonged treatment. 3 months is regarded as the absolute minimum treatment duration. 6 months is suitable for most cases. 12-24 months is needed for severe cases, or for cases affecting certain organs (brain or spine). Anti-TB antibiotics also have severe side effects - liver damage, nerve damage, permanent eye damage, they severely disrupt the biochemistry of other drugs (potentially causing them to become ineffective, or overactive), etc.
In poorer countries, patients/doctors may not be able to afford a full course of drugs, and may therefore cut it short. Uneducated patients may also stop the treatment when they start to feel better, and not carry the course through to the end (and in poorer countries, there may not be a system for doctors/law enformcenet to trace them and bring them back for treatment).
Additionally, tests for TB have are very time-consuming and expensive. It can take 8 weeks to get a drug-sensitivity test, and that's if the test comes back positive anyway (one of the problems with TB, is that it is very good at hiding, and the bugs are very difficult to grow). Where funding is constrained, diagnosis is simply by looking for the bugs in a sputum specimen with a microscope - which tells you nothing about the sensitivities. There is a signficant cost of incubating the specimens on special growth media for 8 weeks, and a low success rate. Because of this, doctors in these countries may not be able to diagnose drug resistance, except when drugs fail to halt the disease after 6 months.
The avoidance of resistance in anti-biotic treatment is best achieved by mixing multiple drugs of different types. Conventionally TB is treated with a cocktail of 3 or 4 drugs. If, however, you use those 3 drugs, ih a population that is infected with a bug that is resistant to 2 of them, then resistance to the single functioning agent, can develop very rapidly.
Things are changing with advanced test kits and DNA amplification technology, which are able to detect the genes that confer resistance, and give a result, with high accuracy and high reliability within 24 hours. The problem is the significant cost of this testing technique.
If you regularly buy from the major storage vendors, you'd know that they already mark up hard drive prices by up to 400%. I think this just indicates that the raw cost of hard drives has got so high, that even with their generous padding, they are feeling the pinch.
My shop is lit with a row of fluorescent tubes and a bunch of very large (200 watt) incandescent bulbs. Winters are brutal on the fluorescent bulbs. They flicker a lot while the ballast warms up. As well we replace more fluorescent tubes each year in the shop than bulbs (why would cold affect the tubes?). Which is nice because the bulbs are 20 feet overhead. Getting reliable, energy-efficient replacements for these bulbs would be very nice but I haven't seen any yet.
The problem with fluorescent tubes is that they need a sufficient temperature to get the correct mercury vapor pressure in the tube. If the pressure is too low, the discharge current will be too low giving poor light out, and an unstable discharge leading to flickering. The tube will need an abnormally high a voltage from the ballast, this will cause excessive sputtering from the tube filaments, shortening the tube life dramatically.
To an extent, the use of electronic ballasts can help, as electronic ballasts operate in an almost constant-power mode, whereas magnetic ballasts act instead as a current limiter. If the tube pressure is too low, the electronic ballast will still deliver near full power to the tube, whereas the magnetic ballast will severely underdrive the tube, leading to a prolonged warm-up time, during which time the tube is overstressed. Electronic ballasts also prolong the life of the tube and improve efficiency and reduce flicker due to the use of high frequency drive.
For extremely cold environements, you need to use low temperature fluorescent tubes. These use a different gas mix and mercury charge, this ensures that the discharge is stable and tube parameters appropriate at temperatures as low as -40 C.
They work just fine. In fact, their higher efficiency makes them a better choice than incandescent for use in fridge/freezer lighting - which is why most commercial fridges/freezers for display use use LEDs.
it's worth pointing out in this case what the reason was that prompted the jury to award such a high award in the first place.
Both of the plaintiff and the defendant in this case are software development companies. In both cases, they produce CAD software for home and home design use. In this particular case, the particular software packages in question were those for kitchen design.
Real view were developing a freeware CAD package which would be supported by premium-priced furniture, appliance and decoration add-ons. In contrast, 20-20, which was already a major player in this market, sold a fully featured package for $4200.
The infringement in this case was that real view had illegally downloaded a pirate copy of 20-20's flagship product, and then used that as part of their development process for their own product. In particular, they effectively cloned the GUI and a number of other features, so that users who had previously used 20-20's product could switch to the new real view product without retraining.
Slashdot Mirror
Bugs and security vulns are almost unavoidable - but some are due to gross negligence. Gross negligence should always be open to litigation. To follow on from Microsoft's analogy, if a door manufacturer was grossly negligent (let's assume that the door includes the lock and hinges - when this isn't normally teh case), and sold a high security door system, but had accidentally keyed all the doors to a single grand-master key. Then if you were burgled because a burglar happened to find out about this grandmaster key, then potentially you have a claim.
I don't see why it shouldn't be too different in software development. A software vendor needs to bear some responsibilty for good programming practice.
Bad software is everywhere; some is so bad, that it does border on grossly negligent.
As an example, I recently reverse engineered an "electronic patient record" system that was installed at a local hospital. This had a number of interesting design features:
1. Password security was via encryption rather than hashing. The encryption was a home-brew modified Vigenere cipher.
2. The database connection string was stored in the clear in a conf file, stored in the user's home directory. Interesting the database connection used the "sa" user.
3. Presumably for performance reasons, certain database tables (notably "users") would be cached in plaintext to the user's home directory. This way, an SQL join could be avoided, and the joins could be done client side.
4. The software ran an auto-updater that would automatically connect to a specified web site and download and run patches as admin - without any kind of signature verification.
5. All SQL queries were dynamically generated strings - no parameters, prepared statements or stored procedure. Not every user input was properly escaped. Entry of a patient name with an apostrophe in it, would cause very peculiar behavior. In the end, regular memos had to go round to staff telling them under no circumstances to use apostrophes in patient names, and to avoid, wherever possible the use of apostrophes in the plain text entries.
This is by no means all the security problems this software had, never mind the bugs e.g. a race condition when synchronising with a second application which would result in the two components opening different patient's charts.
Amazingly, there weren't any security breaches or significant medical errors as a result of this software - but I can't really conclude that this software production was anything other than grossly negligent.
The lead is likely very effective at reducing recorded exposure - probably cutting it by 75-90%. Most of the radiation in a typical fission product incident is beta radiation, which will be substantially attenuated by 1 mm of lead (the beta particles won't get through, but probably 1-2% of their energy may get through as bremmstrahlung X-rays). Gamma rays, will also be attenuated but only by a few % (high energy direct photons won't be significantly affected, but photons scattered from concrete, etc. will be of much lower energy, so will tend to be heavily attenuated).
There are plenty of radiation suits that offer 0.1 or 0.2 mm lead equivalent protection (they don't usually contain lead for environmental reasons, bismuth is usually used instead). These are quite useful for protection against beta energy, even if they do nothing for gamma. However, the sheer weight of even a 0.2 mm lead suit makes it only barely practical (though I understand the US military have bought a lot of them).
However, lead boots are a sensible precaution - most of the radiation in a Fukushima type incident is in the form of water soluble or suspended particles, which pool on the floor in puddles. Severe radiation injury to the feet from beta emitters is possible - 1mm lead equivalent rubber boots are tolerable to wear, and would offer substantial protection to the feet.
Nowadays, people install electron microscopes in their living rooms for use as educational kids' toys. See youtube for examples
I don't think Gibson found a kernel backdoor.
He did should very loudly about an intentional backdoor in the windows metafile image handler, which would start executing native code when a callback command was included in the script. He made a large number of spurious arguments as to why this was clearly intentional, as the vuln could only be triggered in very exceptional circumstances.
He was completely wrong about almost everything he said. The vuln was trivial to trigger, except when it was the last instruction in the script (which was the only way Gibson was testing). From the fact that he had great difficulty triggering it, requiring multiple parameters to be set to nonsense values, he concluded that this was clearly a deliberate backdoor.
It later came out from a number of MS insiders (incl. Mark Russinovich) that metafiles were a feature of Win 3, and were intended to be fully-trusted OS components (for rapid image drawing, and therefore had privileged access to a variety of internal system calls - notably the ability to set callbacks). The functionality was greatly increased in Win95 and later, with the original x86 hand-written assembly being ported directly, rather than rewritten. In the mists of time, the assumption of full-trust got lost.
In most areas where condos exist, the commercial ISPs will offer adequate DSL or cable services. This way, individual residents can make a decision about what service they want, and purchase the DSL or cable service that suits them.
Simply lay down a few ground rules to condo residents: No externally mounted dishes, No new visible cabling in communal areas, etc.
The condo assoc, may be willing to assist in installing ducting - this way, residents can chose fiber, cable, DSL, etc., and it can all go through existing ducting which only needs to be paid for once and won't require new building work when new technology X comes along in 5 years time). In fact, probably the most sensible thing to for a CA to do would be to install some cable ducts running from the basement cable entry point along corridors to individual apartments. That way when a resident wants new cabling installed, all the contractor has to do is install the cable into the ducts and it's job done. FTTP providers may even wish to fill up your ducts with sub-ducts. This is the maximum level of involvement that I would suggest. By having the CA do the duct work, you keep control of quality of workmanship. A particular problem with high-rise blocks is fire codes. Often, they require any hole in an individual apartment to be fully firestopped. This is not a job you should trust to individual network operators, and their low-cost installers. Make a decision to install building wide ducting, and get it properly installed, firestopped and certified.
Running an ISP is a difficult business, both on technical and customer service grounds. The network design is difficult and needs to be done by an expert. Further, how much time are you budgeting for fielding technical support queries, billing, DMCA requests, etc. If you get a DMCA request, which identifies your IP (or one of your IPs), how are you going to forward it to the alleged offender (You've got DHCP server logs, haven't you?) . If you can't forward it, because you don't know, will you face criminal penalties yourself? You might not now, but laws change (in the UK, if you resell an internet service, and a criminal act is committed via it, and you don't keep information allowing you to link an identifiable person with the particular communication, YOU are personally liable).
Similarly, if running a communal ISP, how do the costs work if residents choose not to participate? HSPA+ and LTE dongles are on the market and, where I live, they are killing wired internet and WiFi. I now know many people whose only internet access is a smartphone/tablet with 3G - and that's all they use at home.
Yes, you may be able to get a better service for less money if all 80 residents participate. But what if only 40 participate? What happens when you start getting into legal problems (whether legitimate or not)?
FPGAs commonly protect user-code with encryption. An encryption engine is included in the silicon to which the user has limited access to crypto=keys with which to encrypt the code that is installed in ROM/Flash.
A number of attacks are known against microcontrollers/FPGAs that secure code with encryption - notably differential power analysis (DPA) which works by connecting a current probe to the chip, and collecting measurememnts of energy consumption as the device performs an authentication operation. By carefully, measuring power traces over thousands of authentication operations, statistical analysis can reveal clues about the internal secret keys; potentially allowing recovery of the key within useful periods of times (minutes to hours).
These secure FPGAs contain a heavily obfuscated hardware crypto-engine, with lots of techniques to obstruct DPA (deliberately unstable clocks, heavy on-chip RC power filtering, random delay stages in the pipeline, multiple "dummy" circuits so that an operation which would normally require fewer transistors than an alternative, has its transistor count increased, etc.). The idea being that these countermeasures reduce the DPA signal and increase the amount of noise, making recovery of useful statistics impractical. In their papers, this group admit that the PA3 FPGAs are completely impervious to DPA, with no statistical clues obtained even after weeks of testing.
This group have developed a new technique which they call PEA which is a much more sensitive technique. It involves extracting the FPGA die, and mapping the circuits on it - e.g. using high-resolution infra-red thermography during device operation to identify "interesting" parts of the die by heat production under certain tasks - e.g. caches, crypto pipelines, etc. Having identified interesting areas of the die, an infra-red microscope with photon counter is focused on the relevant circuit area. As it happens, transistors glow when switched, emitting approx 0.001 photons per switching operation. The signal from the photon counter is therefore analogous to the DPA signal, but with a much, much stronger signal-to-noise ratio, allowing statistical analysis with far fewer tries. The group claim the ability to extract the keys from such a secure FPGA in a few minutes of probing with authentication requests.
The researchers claim to have found the backdoor, by fuzzing the debug/programming interface, and finding an undocumented command that appeared to trigger a cryptographic authentication. By using their PEA technique against this command, they were able to extract the authentication key, and were able to open the backdoor, finding they were able to directly manipulate protected parameters of the chip.
You assume that NTLMv2 or kerberos are the default authentication methods. The workstations ran, and still run to this day, XP SP1 as that is the most recent OS supported by the vendor of the software.
XP SP1 uses NTLMv1 as the default authentication method which does not make use of the time during authentication.
This is often a case of poor administration, perhaps more frequently than poor design.
For example, I was recently tasked with reviewing the performance of several hospitals in the diagnosis and treatment of stroke. Under national guidelines (UK) a patient with suspected stroke must have had a CT scan within 30 minutes of arrival at hospital, with blood-thinning treatment administered within 60 minutes (if appropriate).
The problem was that the times on the CT scanners were discrepant by +/- 45 minutes from true time - so the images were tagged with the incorrect time. Further, the CT viewing workstations had times up to 2 hours discrepant. The CT scanners were Windows or Gentoo depending on the manufacturer's preference. Similarly, the CT workstations were windows, and were all bound to the hospital domain.
The time discrepancies made my assessment very difficult - and I had to correct for each individual scanner, and assume that the clocks hadn't drifted over the 6 month period of the audit.
I also found several safety issues because of this - e.g. if it was 1am, and a patient had a CT scan, some workstations would be 2 hours slow, so would read 11 pm on the previous day. These workstations would refuse to load the CT scan because the files were filtered by "WHERE [StudyTime] NOW".
I raised a support issue with the workstation vendor who simply said "These are windows workstations. You should ensure that they are appropriately bound to your domain, and configured to sync with your time server or domain controller". So I called IT to configure this, "No way. These are medical devices, we can't change the configuration - and anyway, what will happen if the clock is fast, and the sync pushes the clock back, so that there are 2 occurrences on the same time. That would cause chaos. Even if the manufacturer supports it, there's no way we'll set it up". Of course, their concern doesn't actually exist, because most time sync algorithms (even on Windows) are clever enough to avoid "double time".
There was similar obstruction with the CT scanners. The vendors simply said - we support and encourage synchronisation with a time server. IT or the radiology administrators simply stonewalled the ideas. They refused even to correct the clocks on teh scanners - so the clocks are still wrong to this day (even more so, due to accumulated drift).
Of course, even if the time can be set right - there is disagreement as to how daylight-saving is managed. Some equipment, esp. older embedded kit isn't daylight-saving aware. Do you set it to Summer time or winter time? In most hospitals I've been in, it's been an inconsistent mixture - often with lots of clock drift added, so you can't actually be sure.
One of the difficulties is that priorities in government sector procurement are often biased in favour of the senior management and doing what is seen to be good politically, rather than usability or manageability.
The difficulty with the govt tender process is that some vendors are unfamiliar with it and don't give the best answers to the questions asked in the initial tender documents.
E.g. I've just been involved with the procurement of a PACS system (digital X-ray archive), and a lot of the vendors simply scored 0 on a large number of points when they returned their responses to the original specification document.
For example (these are not verbatim examples, but fictional examples which I believe accurately depict the problem):
Tender question: Describe how the software ensures compliance with the Data Protection Act (DPA).
Typical bad answer: The software is compliant with the DPA.
(This is a totally meaningless answer - as a result the vendor scores 0 on this specification point).
Typical good answer: The software has features that assist the hospital in meeting the following aspects of legislation: Control of access, control of retention, Prevention of disclosure and assisting staff in preparation of subject access requests.
Control of access: The software provides for password, certificate, hardware token or active directory authentication. There is a role based permissions system with arbitrary complexity - for example, a nurse's login could be restricted to access of patients only on her ward. Permissions can be controlled on a role or user level, and can provide access control on any image, case-record metadata (including custom fields) or metadata available from a connected information system.
Control of retention: Data can be destroyed automatically when no-longer needed. The period can be configured by the local adminstrator according to local policy. A rules-engine is included which permits granualar control of retention based on, for example, patient age (children's examinations can be kept until adulthood, instead of on a data age), type of exmaination (e.g. research studies may need longer retention), manual flags, any image metadata, or metadata from a connected information system.
Prevention of disclosure: All data stores are encrypted with 256-bit AES. Data transmission over the LAN, or public networks, are encrypted using TLS 1.1 with 256-bit AES. If data caching on client machines is permitted by the administrator and local policy, the data is encrypted using 256-bit AES. All system accesses are logged in an audit-trail. Powerful analysis tools, including a rules-engine, are provided to allow investigation of suspected abuse. If the system administrator permits images to be saved to teaching files/powerpoint documents/etc., image metadata containing patient identifiers will be removed automatically. If the images contain patient identifiers in the pixel data, then the images will be redacted automatically (subject to the availability of appropriate metadata in the original image files).
Subject access: The system can provide a full subject access report for both patients and users (staff). The report will include all data, including audit trails, together with summary (the staff report will have patient data redacted automatically), and can be exported to optical disc or hard drive in a single operation.
With an answer like that, it has to score 10/10.
The problem is that most of the software vendors are not very good at understanding the questions - particularly, where they relate to legislation. The big winners here tend to be the big contractors, often infamous in the national press for supply of poor quality solutions. They "get" what the questions are asking, so score big - and this often makes up for less-than-stellar performance in the technical and usability sections of the scoring.
They just put an old OS on. At the hospital I work at, there are a number of critical applications (like parts of electronic patient records, and other custom made apps) which only work on IE6.
That means the brand new workstations we took delivery of last month (dual quad core Xeons, 4 GB RAM, Fire GL Pro cards) have all been loaded with XP 32-bit SP1, in order to get IE6 and avoid some features of SP2 which break a number of other apps.
To be honest, it's a miracle that they're stable, as I can't believe the drivers for the graphics cards, etc. are fully supported on this OS.
Yes. The routers are $6k each. However, the purchase contract specified $16k of add-ons for each router.
It's true that SMS "just works" now. But that is only a recent development.
5 or 6 years ago - SMS across a national boundary was a lottery. It might work, it might not, and you'd have no way of knowing when, or even if, your message was delivered. This was particularly the case with the US, where SMS was particularly unreliable.
Even SMS between individual networks within a country wasn't always as reliable as you might have expected.
The type of lamp you want exists, and is very widely used commercially for shop lighting. It's called ceramic metal halide. A 20W lamp produces about 2200 lumens from a very compact (3-4mm) point source. When used with a reflector, they make excellent accent lighting, and there are plenty of commercial products that install them on tracks, etc. They have excellent color rendering (far better than the best LEDs and fluorescent) and are available in a variety of color temperatures. The lifetime is also long - typically 15,000-20,000 hours. They are even dimmable, although the dimming range is limited (and while the lamps will dim, and there are color shifts).
The efficiency of ceramic metal halide is unmatched by any other commercially available technology (except for sodium lighting).
The problem is the price - which is enormous (partly as these are targeted at commercial use, where replacement labor cost and energy costs/cooling costs dominate; but also because it is inherently an expensive technology), not just in terms of the bulb cost, but the ballast to power it. There are other problems too, such as a long warm up time (60 seconds) the first 15-20 seconds of which result in virtually no light output; and a very long cool down time (5-10 minutes) during which time the lamp cannot be restarted.
Nevertheless, CMH is pretty much the leading lighting technology in high-end retail, for the above reasons. I picked up an old shop CMH unit off ebay, and have it at home - and it is stunning. Brilliant brightness, tightly focused beam, very high color quality, flicker-free. Thankfully, replacement bulbs are available very cheap off ebay - there's no way I'd pay the $50+ retail for the bulbs.
Quite. A lot of our "medical devices" are actually software programs running on PCs. Many of them require a specific environment to run.
I can think of one package that will only run on: Windows XP32-bit (No service pack) and Java 1.4. It simply won't run on anything more recent (no idea why), and the developer of this (very expensive) package has gone bust, and the product is no-longer supported (but the finance department budgeted on a 10 year usable life-span, so it's not getting replaced for 10 years following installation).
I've no idea of the total number of vulnerabilities on the combination of unpatched XP and Java 1.4- but I suspect, the number is substantial.
Medical devices don't just include things like implantable equipment (such as implantable defibrillators, pacemakers, pumps, etc.) but analysis equipment, and more recently computer software running on regular PCs (such as electronic patient records, order management systems, digital X-ray system/picture archiving and communications systems), etc.
Implantable devices have been in the public eye recently because they don't use very secure protocols. Typically, the wireless controller transmits a command prefixed by the serial-number of the implanted device. The device then ignores commands which are not prefixed by the appropriate serial number. This is OK for preventing programming the wrong device in a clinic situation, but a hacker could easily perform a replay type attack to cause the device to administer an inappropriate treatment or dose. One reason that manufacturers have given for this is an extremely limited power budget - strong cryptography simply burns too much energy for a device which cannot be recharged.
One problem that has concerned me as a user of medical software is just how poor the security is on a surprising number of products. One product that I use at the moment is part of an electronic patient record system. This system doesn't quite store user passwords as cleartext in the database. However, instead, it encrypts them with a Vigenere cipher (using the username as key). However, because of excess load on the database server, the software very concienciously caches the entire "Users" table as a CSV file on the client computer. Yes, when I discovered the file, it didn't take long for the Mk I eyeball and my recollection of my password history (which was also documented in great detail in encrypted format) to determine the cipher and what was being used as the key. This was subsequently confirmed by running the binary through a decompiler, which revealed a number of other wonders such as potential SQL injection vulns. Of course, none of that really mattered - there was an interesting file called "C:\epr.ini" which contained such lines as:
[ClientDatabaseConnectionString]
Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=EPRORA)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)));User Id=SYSTEM;Password=pyramid1;
However, even leaving aside such extraordinarily bad software from small IT contractors, even the big-boys in the healthcare arena seem to have problems with basic testing, and anything even vaguely corner-case will often result in strange behavior - and that's just routine use, I can imagine all sorts of vulnerabilities appearing if these software packages were subjected to serious attack.
In fact, even in healthcare systems which are supposed to be paradigms of good design, implementation is often very poor. Professor Ross Anderson in his book "Security Engineering" mentions a national security system used in the UK for securing health records, where an individual user's smartcard contains an individual certificate and permitted user roles, which interact with the software to release the appropriate records. On the face of it, an excellent system - and one that Anderson mentions as an example in his book. For a user, however, the implementation is a disaster area; it's unreliable (depending on a national authentication server - local caching was broken in the first 11 6-monthly releases) and vulnerable to DOS attacks. Authentication with the national server was hopelessly slow (taking up to 5 minutes) so was useless for doctors in a busy environment such as the ER. The Roles are administered on a national level, with no way to override errors in role allocation before the next 6-month release (e.g. the first few releases did not permit doctors to change the brightness/contrast of an X-ray that they were examining - this function was restricted to sysadmins only) - the user role administrators acknowledged that this was a serious problem, but refused to push out a hotfix, instead it had to wait for the next role release. In reality, the nurse in A
It's not the wiring per se but power quality. Voltage fluctuations where the mains voltage goes out of spec (brownouts and overvoltage) are a major cause of problems. Electronic power supplies are often heavily stressed by under-voltage conditions, because they increase their current consumption to compensate, resulting in increased heat production in the power supply. Overvoltage can result in internal components being overstressed.
The other problem is high-voltage "spikes" - ultra-short duration (a few microseconds) increases in supply voltage (to 1-2 kV), due to large electric motors (e.g. HVAC compressors) being switched on or off, nearby lightning strikes, etc. These voltage surges won't affect incandescent light bulbs, but will destroy electronic power supplies instantly. Things like PC PSUs are fitted with surge protectors internally, to protect them from this type of spike. Good quality CFLs and electronic lighting ballasts also contain decent surge protection. However, garbage grade CFLs, often leave out these components to save $.10.
The other problem with CFLs is that they are intolerant to heat. This means that care is needed over the type of fitting. CFLs are not suitable for use in enclosed fittings - they must be open to the air, otherwise you don't get any air circulation and the lamps overheat. While incandescent lamps are frequently-used "base-up", CFLs risk overheating the electronics in the base, when used in this orientation. CFLs are best used "base-down".
If you genuinely think there is an electrical problem at your home - then you want a power quality check. This would normally involve installing a data-logger in your house for a week, to see if there are any significant problems with voltages, spikes, waveforms, etc.
I've taken apart a number of Philips' premium lighting products (both top-end CFLs and also electronic ballasts for fluorescent and high-intensity discharge lamps).
I was pretty surprised to see absolutely nothing but the best components. All the capacitors were either high quality metalized film, ceramic or premium ultra-long-life high-temperature Japanese Al electrolytic from a tier 1 manufacturer.
Similarly, the active components were heavily over-specified 100% avalanche rated rugged MOSFETs, with high quality protection (diode clamps and current limiting resistors) on the gate drives.
While cheap Chinese CFLs often use garbage grade components - I was pretty surprised at the quality of the commercial lighting products - but then I suppose that's why these units command such high prices.
Whitechapel already has a station with 3 lines.
In fact, you know that things are strange in Whitechapel, because the underground trains run overground, and the overground trains run underground.
Illegal it may be, but trespass is not a crime. It is a civil offence only (except in certain circumstances, e.g. high-profile areas, railways, etc.)
I've seen a number of projects like this.
I've seen one landfill with a couple of 1 MW generators selling electricity to the grid. Another, sells the gas to the nearby village for use for heating the community centre.
Most recently, I've seen one where the landfill gas is captured and used to fuel the garbage trucks. (Diesel/CNG dual fuel).
Some of it is. TB requires prolonged treatment. 3 months is regarded as the absolute minimum treatment duration. 6 months is suitable for most cases. 12-24 months is needed for severe cases, or for cases affecting certain organs (brain or spine). Anti-TB antibiotics also have severe side effects - liver damage, nerve damage, permanent eye damage, they severely disrupt the biochemistry of other drugs (potentially causing them to become ineffective, or overactive), etc.
In poorer countries, patients/doctors may not be able to afford a full course of drugs, and may therefore cut it short. Uneducated patients may also stop the treatment when they start to feel better, and not carry the course through to the end (and in poorer countries, there may not be a system for doctors/law enformcenet to trace them and bring them back for treatment).
Additionally, tests for TB have are very time-consuming and expensive. It can take 8 weeks to get a drug-sensitivity test, and that's if the test comes back positive anyway (one of the problems with TB, is that it is very good at hiding, and the bugs are very difficult to grow). Where funding is constrained, diagnosis is simply by looking for the bugs in a sputum specimen with a microscope - which tells you nothing about the sensitivities. There is a signficant cost of incubating the specimens on special growth media for 8 weeks, and a low success rate. Because of this, doctors in these countries may not be able to diagnose drug resistance, except when drugs fail to halt the disease after 6 months.
The avoidance of resistance in anti-biotic treatment is best achieved by mixing multiple drugs of different types. Conventionally TB is treated with a cocktail of 3 or 4 drugs. If, however, you use those 3 drugs, ih a population that is infected with a bug that is resistant to 2 of them, then resistance to the single functioning agent, can develop very rapidly.
Things are changing with advanced test kits and DNA amplification technology, which are able to detect the genes that confer resistance, and give a result, with high accuracy and high reliability within 24 hours. The problem is the significant cost of this testing technique.
If you regularly buy from the major storage vendors, you'd know that they already mark up hard drive prices by up to 400%. I think this just indicates that the raw cost of hard drives has got so high, that even with their generous padding, they are feeling the pinch.
My shop is lit with a row of fluorescent tubes and a bunch of very large (200 watt) incandescent bulbs. Winters are brutal on the fluorescent bulbs. They flicker a lot while the ballast warms up. As well we replace more fluorescent tubes each year in the shop than bulbs (why would cold affect the tubes?). Which is nice because the bulbs are 20 feet overhead. Getting reliable, energy-efficient replacements for these bulbs would be very nice but I haven't seen any yet.
The problem with fluorescent tubes is that they need a sufficient temperature to get the correct mercury vapor pressure in the tube. If the pressure is too low, the discharge current will be too low giving poor light out, and an unstable discharge leading to flickering. The tube will need an abnormally high a voltage from the ballast, this will cause excessive sputtering from the tube filaments, shortening the tube life dramatically.
To an extent, the use of electronic ballasts can help, as electronic ballasts operate in an almost constant-power mode, whereas magnetic ballasts act instead as a current limiter. If the tube pressure is too low, the electronic ballast will still deliver near full power to the tube, whereas the magnetic ballast will severely underdrive the tube, leading to a prolonged warm-up time, during which time the tube is overstressed. Electronic ballasts also prolong the life of the tube and improve efficiency and reduce flicker due to the use of high frequency drive.
For extremely cold environements, you need to use low temperature fluorescent tubes. These use a different gas mix and mercury charge, this ensures that the discharge is stable and tube parameters appropriate at temperatures as low as -40 C.
They work just fine. In fact, their higher efficiency makes them a better choice than incandescent for use in fridge/freezer lighting - which is why most commercial fridges/freezers for display use use LEDs.
it's worth pointing out in this case what the reason was that prompted the jury to award such a high award in the first place.
Both of the plaintiff and the defendant in this case are software development companies. In both cases, they produce CAD software for home and home design use. In this particular case, the particular software packages in question were those for kitchen design.
Real view were developing a freeware CAD package which would be supported by premium-priced furniture, appliance and decoration add-ons. In contrast, 20-20, which was already a major player in this market, sold a fully featured package for $4200.
The infringement in this case was that real view had illegally downloaded a pirate copy of 20-20's flagship product, and then used that as part of their development process for their own product. In particular, they effectively cloned the GUI and a number of other features, so that users who had previously used 20-20's product could switch to the new real view product without retraining.