That's no vulnerability
It's a deliberately coded backdoor. Time to start investigating why it was added to the firmware, and who was behind it.
590 posts • joined 3 Nov 2007
It's a deliberately coded backdoor. Time to start investigating why it was added to the firmware, and who was behind it.
What employees? They're all independent contractors.
Most shops don't have the ability to fabricate or program components like this; I'd worry about problems starting much higher in the supply chain. I can see a (probably Chinese) component manufacturer being paid to include ad-injection code. Not terribly different in principle from the bloatware cruft that PCs come preloaded with so often, but much harder to get rid of.
As far as user experience, this wasn't a bad idea. It's fairly common in some industries (e.g., restaurants) to provide worst-case estimates of wait times, so that when customers are provided service sooner than estimated, they are pleasantly surprised. So it's not unreasonable to give the passenger one estimated arrival time, while giving the driver a route that will get there slightly earlier, barring unexpected traffic delays.
What will get them in trouble is if they have been calculating charges and payments separately, as the lawsuit alleges. Without highly-improbable macroscale quantum effects, both routes cannot be taken at the same time, so either passengers are being charged for more time and distance than they actually spent in the car, or drivers are being paid for less time than they actually spent driving. Whichever one it is, that's a pretty strong case for fraud.
It's the same reason many companies have switched to electronic door locks. When properly implemented, each person has a unique access code. Hard to duplicate, usage can be tracked, access can be revoked without affecting anyone else. Of course, when it's not properly implemented – as in this case – it ends up weakening security.
I've been struggling to come up with a reasonable situation in which one would do this.
If you're sending video from one webcame to multiple recipients, you're probably using a single program to do it.
Using multiple programs for multiple video sources could make sense (for example, videoconferencing on a webcam while sending security camera footage to archive storage), but that situation is unaffected by this change.
I suppose you might want to split a video source if you want to stream live footage over the internet and record it at the same time, but only if you're using brain-damaged programs that can't do both.
A lot of FOSS isn't signed – many developers don't seem to want to bother with the hassle – so the warning isn't too unusual. The only way it would have prevented an infection is if someone had installed the program enough times to notice that it's usually signed, but this time it wasn't.
They are both alliums, but they are not interchangeable.
The 'we never change our passwords' bit suggests that they found his login information in a data dump from a years-old breach and decided to see if it still worked.
Interesting idea. Since it seems to have trouble with too many things moving at once, I wonder if it would work better for desktop monitors and large, fixed displays rather than phones.
At least Microsoft has helped answer the question of why women don't want to work in the tech industry.
As long as they keep at least one ongoing investigation using a given vulnerability, it never has to be disclosed. If they're only using an exploit on one person, drag out that investigation until they can get another one started.
To be pedantic, organic chemistry originally was the study of compounds found in living things, and inorganic chemistry was everything else. After Friedrich Wöhler demonstrated that urea (a known organic chemical) could be synthesized from inorganic compounds, they had to scrap that definition and redefined organic chemistry to be about carbon instead.
Ads based on a celebrity event, or sports game, or TV show are reasonable. Nobody really likes ads, but they can understand why they're there and no one will raise a fuss about it.
Then someone like David Bowie dies, and everyone talking about it sees ads for Bowie-themed merchandise, and it looks like a crass attempt to cash in on someone's death.
Then you get an incident like what's currently going down in Orlando, Florida, and everyone sees ads for guns. People get upset, looks like Twitter is happy to profit from a tragedy, lots of drama and PR damage control.
So maybe this isn't the best idea.
The problem with having a software-defined return address stack is that there's nothing to keep malicious code from manipulating it; as far as the processor is concerned, it's just another region of the process' memory. A hardware-defined shadow stack can more effectively restrict access: the processor itself is the only thing that should manipulate this area of memory (as a side effect of call and return instructions), so any attempt to alter it directly can trigger an exception.
I'm not intimately familiar with x86 instructions (I'd rather be dealing with Power or ARM), but it looks like this could be defeated if there's a way to write arbitrary data to the EIP register. Overwrite EIP, call the next instruction, and you've put your desired return address on the shadow stack.
If someone steals the database, they don't need to reverse the hashes. They'll just throw a dictionary file at your hashing algorithm and look for matches. Doesn't take too long to brute-force every password up to 6 or 8 characters long as well. This is why you should be salting the passwords before hashing them, and forcing users to have sufficiently long passwords.
I suspect the ad networks' inaction is a deliberate strategy, even though poisoned ads have been a known problem for years. As long as they act as a neutral host without filtering anything, they can claim they're not liable for anything that happens. If they try to block bad ads, they could be blamed for anything that they don't catch.
Corporate lawyers can suck snozzberries.
A tub of hummus is quite useful – and delicious.
I think it's just a matter of efficiency: the hash is much shorter than the original message, so encrypting and decrypting the hash takes less time than double-encrypting the entire message.
bans both slavery and involuntary servitude (except as punishment for a crime), so it's actually quite relevant here. The judge may not agree that it's a good argument, but it's not unreasonable to try to make that argument.
The biggest problem I see with the OpenSSL code is that it leaves you at the mercy of your compiler/optimizer. You have to trust that the optimizer will properly traverse all possible code paths and not strip out the entire if (0) block as unused/unreachable code. It may work fine for whichever compiler and optimization settings the developers used, but there's no guarantee it will work for everyone else.
If Nokia hadn't sold out to Microsoft and killed Symbian, there might still be a viable alternative for manufacturers to switch to. Ironically, it probably would be easier for Win10 to get a foothold in the market if it was more fragmented between iOS, Android, and Symbian.
Definitely not obvious - at least it didn't end in a 5 - but at the same time, any decent factorizing program would have reached 271 fairly quickly, so it's clear they didn't double-check the number in the code for primeness. Since one of the factors is so small, my guess is there was a typo of some sort; if I wanted to backdoor an encryption routine, I'd use a semiprime whose only two factors are roughly equal in length (~150 digits in this case), so it would take some significant number crunching to discover that it's not prime.
As I recall from when the FCC was soliciting comments on net neutrality, they essentially analyzed responses for uniqueness and discarded duplicates. Seems like a good way to keep form letters from dominating the responses without having to scrap the entire thing.
They were also just the right size to use as blast shields for model rockets.
ISP filtering makes a lot more sense. If malicious traffic is detected coming from a particular IP address, they can sinkhole anything coming from it until the issue is fixed. Redirect any webpage requests to an information page explaining the issue and how to obtain tech support to fix it. No backdoors needed, and if they ever finish rolling out IPv6, individual devices can be blocked rather than cutting off an entire household.
"The company I started lost money, so I'm going to sue them to take even more of their money, because somehow that will fix things."
11 billion device-hours in December using Windows 10. 200 million monthly active Windows 10 devices. 31 days in December.
On average, each device is being used for 55 hours per month; less than two hours per day. Of course, some get used much more than that, which means many of their 'monthly active devices' are hardly being used at all. Not exactly encouraging numbers.
that they redacted the email. Would be nice to expose some of the people who are behind this crapware.
Another problem: I'll bet the URI the voice data is sent to is hard-coded in that firmware. Hack the home router (and frequent Reg readers will know how secure those are), set a rogue DNS, and a malicious server can intercept everything it transmits. Knowing how well IoT devices are designed, there probably isn't any attempt to verify the identity of the server it's talking to.
The manual says it will automatically download and install software updates. Hopefully that process isn't vulnerable to the same sort of MITM attack.
Might work well in welding helmets; the autodarkening ones are already powered by photoelectric cells.
The article talks about how hard and stiff this glass is, but for a screen you really want toughness and a bit of elasticity. When a phone is dropped, it should be able to flex slightly to absorb the impact without cracking.
2) The size of a struct can be determined at compile time, no need to store it in a variable. Hardcoding the value isn't a good idea, as it reduces platform independence, maintainability, and readability.
3) I'm not familiar with the code in question, but 'mtu' is probably a local variable, initially set to the MTU size and decremented as a packet is processed. You could use a 'packet_size' variable instead, but then you'd have to look up the MTU size every time you check for overflow, whereas this way you just check if 'mtu' is negative or not.
Write a program that makes substitutions only in variable names and classes/structs/etc. (but not standard library ones). The code will still compile and run the same, but trying to change it would be a nightmare. Might be useful if you have to let someone see your code, but don't want them to steal it.
There's a save feature in the Virtual Console version on the Wii/3DS, but definitely not in the original.
Even with that typo fixed, it still doesn't make sense gramatically: "since [they] have decided Flash into either won't play or won't play automatically". Seems like someone started writing one sentence, got distracted, and came back and finished a slightly different sentence – I've done this myself more than a few times.
Also, the badness of Flash has been discussed to death here already. Mocking typographical errors is more entertaining than reading the same comments over and over again.
Someone showing common sense and decency? Have an upvote!
we stopped giving people attention for being stupid?
'HERE' is actually the name of the map company: here.com . Still could use a link, though.
Nice example of how this can spread access to a network without the owner's consent.
If every device used Sense, it wouldn't be as bad an idea. The network owner is the only one who enters the key, it's shared with their friends and no further, everyone's happy. (Of course, as other people have pointed out, this ignores the reality that many people have contact who are not trusted friends.)
If nothing uses Sense, it's possible for friends to pass on wifi keys, but it requires a deliberate action. John could choose to give Mary's key to Charlie, but it's not something that can happen accidentally.
The problem is when you mix key-sharing methods. Maybe Mary uses a Mac and has never heard of Sense. Maybe she uses Windows 10 and turned Sense off because she doesn't want her wifi key shared with everyone she's ever contacted, which includes Charlie. Either way, when John enters the key on his Windows phone, it assumes he owns the network and has the authority to share the key with everyone he knows. Since John isn't tech-savvy, he isn't aware of Sense and hasn't turned it off; he doesn't even know that Charlie now has Mary's key.
The only way I can see this being workable is if it's fully opt-in: choose to share a key, and choose who to share it with, rather than sending it to all of your contacts.
RTFA: "Microsoft enables Windows 10's Wi-Fi Sense by default, and access to password-protected networks are shared with contacts unless the user remembers to uncheck a box when they first connect."
When your friends connect, do they share the key with all of their contacts? No matter how secure the keys are as they pass through Microsoft's servers, the plaintext has to be recoverable for their devices to make use of it, so is there any way to prevent it from being spread ad infinitum?
So, they release build 10158 saying it has "no significant known issues". A day later, they release build 10159 with 300 fixes. They must have known about these issues in order to fix them so quickly, and at least some of them must have been significant enough to justify releasing another build so soon.
This sort of disingenuity is why a lot of us don't trust Microsoft.
Because video is easily the largest use of data. If all of Sprint's customers were watching Netflix at the same time, they'd be pulling 80 terabits per second across the network - some 200 times as much as the largest DDOS attacks ever recorded.
Really depends on the display resolution. If you can see the pixels, it will detract from the overall experience. A slight defocusing could help blend the pixels together without causing distortion.
The Oculus part looks disappointingly cheap. Single lens, rather than compound (which is probably why it has that chromatic aberration). The support ribs on the bayonet flanges suggest it's made of thin plastic, probably flexes if you squeeze the sides of it. Hard to tell what's holding the lens in place, looks like it could pop out fairly easily if you tried. In comparison, the Microsoft part looks more like my vintage telescope eyepieces.
I think Sand Hill's approach was much like Uber et al.: try something new, ignore relevant regulations by claiming they don’t apply to what you're doing, and hope that by the time people decide the regulations do, in fact, apply, you're too successful to be shut down easily. A more cautious approach would have been to start by going to the regulators and trying to get a change in rules, or an exemption for what you want to do. Having Nobel-prize-winning economists saying it would help stabilize markets and prevent bubbles would certainly help with that.
According to HP, they reported it to Microsoft some eight months ago; their initial report in February said they’d already given Microsoft 120 days to respond. When they sit on a vulnerability in the latest version of one of their flagship products for that long, then decide they don’t want to fix it, they don’t have any right to tell people to not talk about it.
MediaWiki renders each article - including templates used - into a single HTML page, so complex articles won’t be any slower to load than simple ones. Articles with a large number of images may require more connections, but that’s true of any site.
I agree that most articles aren’t sensitive, but how do you determine which ones are? If someone is at a sensitive page sent through HTTPS and browses to a non-sensitive page sent through HTTP, their history will be revealed through the Referer: header. If the server has any way to say "you’re not looking at a sensitive page, I’m switching back to HTTP", there’s a MITM encryption-downgrade attack waiting to be found. It’s much simpler to just encrypt everything and not worry about the details.
The .NET CLR is a virtual machine.
At least it wasn't the one with the fancy espresso machine in it.
Biting the hand that feeds IT © 1998–2018