Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Google searches (Score 2) 152

I always thought there would be a mine of information based on a company's searches too. Engineer is reading a spec and googles an acronym, finance google a company they are planning to merge with, HR google potential candidates, R&D google research terms, etc. Not too much of an issue if you have no other interaction with google, but if your company competes with google or otherwise has a business relationship with them, then it may be a good idea not to google anything!

Comment Re:The car is great to drive, but... (Score 1) 222

Hmm, the obvious solution is to filter out finger movements due to bumps by shifting the screen in the opposite direction. Accelerometer sensors would provide the inputs, along with "anticpational imaging", i.e., a camera that tracks generalized finger movement and plots out the likely tradgectory. It'd be like a steady-cam, but for the touchscreen. Alternatively, you could be boring and have a knob or button.

Comment Re:sTEM (Score 1) 219

I hope someone mods you up because I've been asked by high-schooler's "what's the difference between Computer Science and Computer Engineering?" and I've answered in pretty much the same way, except your answer is better. I'd like to add that on top of what you've written, there are a lot of other tasks/skills/jobs that go into getting successful software products out the door. E.g., Product Owners, Scrum Masters, Build Team, Test Team, Customer Engineering, etc.

Comment Not a programmer, but I use coding a lot at work (Score 1) 217

I'm not a professional programmer - OMG, if I was, I'd shudder to think what would happen - but I did programming back as school in the 80's and 90's and have kept it up as a hobby ever since. I'm one of those engineers who went into product management and I've found coding terrifically helpful as a tool at work, just like presentation skills, personal skills, negortation skills etc. I've used it to create demo content for conferences (ActionScript) (got an award for that one), analyze customer requests via simulating their proposed algorithms and showing they were ineffective (Java), deduce requirements for lifetime UV exposure of a product (Matlab, Excel), model product uptake, etc. etc. When I get stuck, I work with engineering, but I like to keep them focused on their real job. Having a mindset that knows you can apply code to data and get answers is super important. Even knowing that this is possible would be one step up from nothing.

Comment Re:Who Exactly Gets To View a Company's Code? (Score 1) 126

Read the court documents on Toyota's ECU software sometime, to see what 'researchers' found when they were allowed to look at it.

Mirroring (where key data is written to redundant variables) was not always done. This gains extra significance in light of
Stack overflow. Toyota claimed only 41% of the allocated stack space was being used. Barr's investigation showed that 94% was closer to the truth. On top of that, stack-killing, MISRA-C rule-violating recursion was found in the code, and the CPU doesn't incorporate memory protection to guard against stack overflow.
Two key items were not mirrored: The RTOS' critical internal data structures; and—the most important bytes of all, the final result of all this firmware—the TargetThrottleAngle global variable.
Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.
Toyota's ETCS used a version of OSEK, which is an automotive standard RTOS API. For some reason, though, the CPU vendor-supplied version was not certified compliant.
Unintentional RTOS task shutdown was heavily investigated as a potential source of the UA. As single bits in memory control each task, corruption due to HW or SW faults will suspend needed tasks or start unwanted ones. Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration.
A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks.

Source Link: http://www.edn.com/design/auto...

Submission + - Book Review: Abusing the Internet of Things - Blackouts, Freakouts, & Stakeo (amazon.com)

sh0wstOpper writes: author Nitesh Dhanjani
pages 96
publisher O'Reilly
rating 9/10
reviewer Dan Smith
ISBN 1491902337
summary Attack & penetration techniques for the Internet of Things

The topic of the Internet of Things (IoT) is gaining a lot of attention because we are seeing increasing amounts of 'things', such as cars, door locks, baby monitors, etc, that are connected and accessible from the Internet. This increases the chances of someone being able to 'attack' these devices remotely.

The premise of "Abusing the Internet of Things" is that the distinction between our "online spaces" (example social media, email, online banking) and our "physical spaces" (homes and offices) will become harder to define since the connected objects supporting the IoT ecosystems will have access to both. For this reason, there is concern that attacks originating online may not only head to impacts such as the loss of personal data, but actually cause physical harm.

Here is my take on the content per chapter:

1. Lights Out—Hacking Wireless Lightbulbs to Cause Sustained Blackouts
In this chapter, the author takes apart the popular Philips hue lighting systems by examining the various types of communication protocols (Zigbee, TCP/IP). Packet captures of communications between various systems are presented in an easy to understand fashion. An actual vulnerability that can be abused to cause a blackout is also described.

This chapter also discusses how the lighting system and other IoT objects are starting to integrate with each other using the If This Then That (IFTTT) platform. As such, cross-platform vulnerabilities are discussed. I appreciated this section in particular because it did a good job of helping me think of how attackers are likely to leverage the fact that various IoT devices will want to integrate with each other and the compromise of one device can give someone access to other devices.

2. Electronic Lock Picking—Abusing Door Locks to Compromise Physical Security:
There has been a lot of research in the area of wireless door locks. It is easy to see how a simple vulnerability in such a device can compromise physical safety. This chapter clearly articulates vulnerabilities in popular door locks in hotel rooms and how they have been already abused for theft. This chapter also discusses security issues in the Bluetooth Low Energy protocol and closes with good recommendations for consumers as well as for people responsible for designing locks.

3. Assaulting the Radio Nurse—Breaching Baby Monitors and One Other Thing
I found this chapter interesting because it covers the “saga” of popular audio and video monitors manufactured by a company called Foscam. Many researchers have published multiple vulnerabilities in these monitors and this chapter shows how to actually locate hundreds of thousands of exploitable monitors on the Internet. This chapter shows how discussion on Foscam’s own user forums have exploded vulnerabilities.

The Belkin WeMo baby monitor (audio only) is discussed next along with packet captures to show communication details. I like that this book lists such details because it helped me understand how the IoT devices are designed and that made me easier to understand the cause of vulnerabilities.

Real stories of concerned parents as well as incidents of how pranksters have been able to scare parents are also discussed. This really drives home the fact that security issues in these products are being exploited.

4. Blurred Lines—When the Physical Space Meets the Virtual Space
The topic of concern of this chapter are IoT based devices that can be leveraged to protect physical safety. The popular SmartThings suite of IoT devices are the scope of this chapter. Security issues that include hijacking credentials, abusing SmartThings’ own IDE platform, and SSL validation vulnerabilities are described.

5. The Idiot Box—Attacking “Smart” Televisions
I enjoyed this chapter in particular because it walks through multiple security vulnerabilities targeting multiple products of one vendor: Samsung. The chapter describes the “TOCTTOU” attack and how it’s exploited. I’ve tried to read the original researcher’s white paper on this attack and found it confusing but this chapter described it elegantly and I was then able to go back and read the white paper easily.

Bad encryption is the focus of this chapter and I laughed at the heading “You call that encryption?” followed by the sub-heading “I call that encraption”. These sections talk about how badly encryption (using XOR) by Samsung have been used to reverse engineer code. The section ends with the line “The slang term *encraption* (with the emphasis on *crap*) is affectionately used by the cyber- security community to call out badly implemented encryption. As this case shows, the title of this section is entirely justified.”

Since the chapter is focused on one company, the author does a good job of equating the situation to other companies in the past (such as Microsoft) and how systemic security issues like these should ultimately be addressed by the leadership so that security is embedded into the DNA of the company. I found this perspective valuable.

6. Connected Car Security Analysis—From Gas to Fully Electric
The topic of car hacking is one of the reasons I bought this book. I have heard of the author in the past based on his research on the Tesla Model S since I came across his presentation at the Black Hat conference last year. This chapter includes emphasis on the Tesla along with how the back end API works to support features such as locating the car remotely, unlocking it, and even starting it. The lack of 2 factor authentication is an an issue that gives rise to simple technique like phishing that can be used to steal a Tesla. Developers are insecurely leveraging Tesla’s API in a way that is making car owners send over their clear-text credentials to them. I am amazed that this is currently happening and most Tesla owners don’t even know that they are basically handing over their keys to people who they don’t know.

This chapter also covers popular research by Chris Vaslek and Charlie Miller, along with remotely exploitable vulnerabilities in telematics systems which has gained a lot of media attention and concern recently.

7. Secure Prototyping—littleBits and cloudBit
I found this chapter refreshing because it approaches security from the eyes of someone who wants to design a new IoT product. The chapter walks though a design of a wireless door bell using the littleBits IoT platform which is primarily focused on prototyping. The main point of this chapter is that it is much more valuable to design security earlier on in the prototyping stage than deal with security bugs later on in the process. I liked that the chapter uncovered security flaws earlier on in the prototyping of the wireless door bell and tied it back to vulnerabilities found in previous chapters in existing IoT products.

A comprehensive list of threat agents, i.e. the types of entities that may attack an IoT device is presented. This list includes nation states, terrorists, criminal organizations, disgruntled employees, hacktivists, vandals, cyberbullies, and predators. The author does a good job of demonstrating that it is useful to take the use cases of IoT devices and see how each of these threat agents may want to leverage vulnerabilities to achieve their own goals.

The last topic covered here is the concept of bug bounty programs and why it is important for IoT companies to reward researchers who submit security bugs to them for free. I’m close to implementing such a program in my organization so I felt the content in this section was spot on.

8. Securely Enabling Our Future—A Conversation on Upcoming Attack Vectors
Looking into the future, this chapter goes through very interesting methods in ways IoT ecosystems can be exploited, starting with the deployment of drones to track individuals, a group of people, or even take over a city. A ‘cross-device’ attack scenario (with code) to show how a website on a victim’s laptop can verbally instruct the Amazon echo to turn lights off was fun an thought provoking, i.e. the fact that IoT devices around us will be able to tell each other what to do and how this can lead to chaos. In addition to other threats in our future, this chapter opens up discussion on the security of interspace communication (with respect to our goals to send manned spacecraft to mars) and also the importance of treading carefully when it comes to super intelligence.

9. Two Scenarios—Intentions and Outcomes.
This chapter includes 2 short stories, i.e. “hypothetical scenarios” of an security executive abusing the “buzz” around IoT and failing to think of how to secure his company because of lack of strategical thinking. The second short story demonstrates how IoT companies also need to think of human elements, emotions, and public relations in addition to the technical content in this book.

Overall, I enjoyed this book and I would recommend it to others. I do feel that a lot of the content can be absorbed even if the reader isn’t technical, but there may be some parts that may be frustrating to someone who doesn’t understand basic concepts of HTTP, TCP/IP, and/or some coding. After reading this book, I feel I have a better grasp of what IoT means to us and what security issues we are facing, and will face.

Submission + - Xerox Creates Printed Labels With Rewritable Memory (computerworld.com)

Lucas123 writes: Xerox has announced a line of printed labels that can store up to 36 bits of data that can be used to track shipped products, determine the authenticity and condition of products, and even identify if a medication refill has been authorized, or if a shipping tax has been paid. The key verification features, which are targeted at thwarting counterfeiters, will work offline, allowing secure validation of an object or process without being bound to the Internet. The memory labels can be encrypted for added security and can store up to 68 billion data points.

Submission + - Confronting A BIOS Hack With A .BAT? (wired.com)

TheGip writes: I have been researching the recent flap in BIOS hacks mentioned here and elsewhere lately and was looking at a creating shutdown/startup batch file that would flash the BIOS with a known good backup BIN on every recycle. Has anyone been doing this? If done wrong how would you recover from being bricked? Should machines come with a second BIOS chip just in case?

Submission + - Drone Hobbyists Find Flaws in 'Close Call' Reports

An anonymous reader writes: The people and agencies pushing for strict drone regulation have no trouble coming up with a list of dangerous drone-related incidents. This includes not only the recent drone crashes that have been picked up by the media, but also reports of "close calls," where drones have allegedly approached full-size aircraft. But a new study by drone hobbyists finds that most of these "close calls" were anything but. Of 764 such incidents reported to the FAA, only 27 were actually described as "near misses" by the pilots involved. None of the incidents involved mid-air collisions, and some have involved military drones rather than hobbyist ones. The people who did the study suggest that we should find a better way of classifying these drone-related situations so legislators have accurate information from which to design regulations.

Submission + - Superadvanced alien civilizations probably don't live in our cosmic neighborhood (sciencemag.org)

sciencehabit writes: If there are superadvanced civilizations out there in the nearby universe, they’re hiding themselves pretty well. So concludes an astronomer in the Netherlands who looked at a sample of galaxies that shine unusually brightly at midinfrared wavelengths—a sign that they may harbor a so-called Kardashev type III civilization, one that has the technology to harvest energy from stars across an entire galaxy. Russian astronomer Nikolai Kardashev proposed in the 1960s grading civilizations by the energy they used: the output of their home planet, their home star, or their home galaxy. A type III, galaxy-wide civilization could hypothetically surround all stars in energy-harvesting “Dyson spheres” but these would nevertheless leak a lot of waste heat in the midinfrared. A U.S. team last year drew up a list of several hundred bright midinfrared candidates from 100,000 local galaxies. But the new study concludes that the midinfrared brightness of most of the sample galaxies probably comes from natural processes, such as dust clouds heated by regions of active star formation. And if there are Kardashev type III civilizations out there, they are either very rare or have the technology to hide their infrared emissions.

Slashdot Top Deals

Make headway at work. Continue to let things deteriorate at home.