Re: Remember that the FBI is seriously criminal
Look up 'ad hominem attack', please.
70 publicly visible posts • joined 23 Apr 2018
Sometimes developers will mask the static code analysis results (mark it inapplicable or something) so it avoids the reviewer's inspection. Sometimes the code is just not analyzed. Sometimes the software is supposed to be just a 'tool' and not considered important. Sometimes developers don't understand what it means. Sometimes the managers override the engineers. Also, peer code reviews can get a bit chummy.
Pretty reprehensible.
Mostly, when you see one such mistake, look for more of the same.
Most employees have company confidential information, sometimes information belonging to OTHER companies. For example, it could be financial, technical, security, personnel, etc. related. So AAPL will not only be concerned about the border cops access to AAPL information but also be very concerned if someone else's information is compromised.
I wonder how lawyers handle this; they carry information covered by attorney-client privilege. Are there cases of the border cops attacking lawyers?
I have been photographing with a 3kg full-frame Nikon setup but it gets harder and harder to justify the back and shoulder pain. Also the best camera is the camera you have.
There is a limit to the resolution that can be achieved by a small lens (Raleigh diffraction criteria). Small aperture lenses still create problems for me while shooting nature. But the Nikon lens is close to a Kilogram.
I prefer to shoot RAW and spend more time post processing than the actual shooting. Are raw+jpeg supported?
It is not a security hole if only our spy agencies can exploit them. Didn't you get that memo? From the report it seems that EVERY spy agency can exploit Huawei's products. /Sarcasm. However, sarcasm aside, I really think that the US was actually serious when they said the Huawei products were really open like a gown that they give you to wear in hospitals.
The issues isn't really if there was a security hole; there will always be vulnerabilities. Cisco has processes in place to reduce these vulnerabilities. And the idiot who came up with the mitigation should not have received an OK from the security team. And Cisco doesn't make money off the their small stuff. So they are guilty to some degree too.
However, Huawei has no processes or they are ineffective. Big difference.
I have dealt with organizations like this ... Top Mgt. gives lip service, hires a few security experts, the developers get trained and every time the developers want to make a change the managers pull out the "schedule slip" card. The engineers go cowering to their corner. Please don't blame the engineers (that much). I even worked in an org which refused to allow static code analysis.
This will only work if every manager has security as part of his KPI. Every fix should be celebrated, every slip should be evaluated for how it could have been fixed. I found that secure code actually runs more reliably. And for people screaming about performance: crashed software has no performance. Buggy software has 0 performance. And hacked software has negative performance.
Come to think of it I can see this being turned on incrementally. Critical outward facing modules first running the checked version (turned on by another #define). I remember a system refused to boot after we turned on stack protection ... I guess we had, unknowingly, been corrupting parts of the stack for a long time. It was a brutal fight to get the developers to go find and fix the issues.
Way back when I was at Sun and we were fighting MSFT (you know who won). I went to a UPnP conference in Redmond and I asked an unnamed architect about security. He said that there was absolutely no security (at that time) and it would actually make things worse. I was surprised at his candor but MSFT does hire some really smart people. Moral of the story: it is all about business. There were better protocols, better solutions. MSFT did what worked for them. The rest of the industry bought into the dream and are now picking up the pieces.
Initialization Vector: In general, "Hello World" would encrypt to a different cipher string if you add a constantly changing Initialization Vector (IV) in front of the real message. Most IV's are at least pseudo random or monotonically incrementing counters. (simplifying here)
M = "Hello World"
Key = k
IV1 = "bwbwebvw"
Ciphertext1= Encrypt ("bwbwebvw" + "Hello World", k)
IV2 = "bcebbewbb"
Ciphertext2 = Encrypt (IV2 + "Hello World", k)
Ciphertext1 =/= Ciphertext2
After decryption you strip out the IV.
In your, if the protocol uses CBC, the last encrypted block would be fed into the encryption engine as IV for the next block; only the first IV would be a real IV. I am skipping over some obvious vulnerabilities reported especially where padding is concerned.
Agreed. I have implemented many a class loader and this problem would have been caught by the byte-code verifier. We never thought it was a good idea to punt on the byte-code verifier but do remember that the earliest SIMS were very underpowered.
SIMs nowadays are more powerful and can use byte code verifiers and decent class loaders.
To add: The issue here is not Java or its architecture. It is the off-card verification adopted by the Java Card standards bodies. For this to work, the applet signing keys have to be compromised and the hacker has to slip in a malformed class file; they can go to the guys who hacked Asus for lessons. I don't want to dismiss the threat; instead of two barriers we now have only 1.
I have no idea why they got a husky. Hudkies are really amazing dogs but ... Huskies talk back to you, argue with you, are high energy, loyal, need activities that you participate in, will invent said activities, and will get destructive if they are not engaged.
I know; I attend to dogs at the local shelter and the huskies are the most fun.
I, for not a single moment, believe that the Intel security team did not realize that there were security holes. I think that they were, like in most companies, pushed aside. It was a business tradeoff. Most businesses have to make trade-offs based on the projected Loss. Speculative instruction execution, always raises the hackles in most security engineers. I remember quizzing a certain chip vendor about it and they were not surprised by my line of questioning.
Intel will only change if the market pressure is high enough or because of regulations and fines. Maybe GDPR can be used against Intel. The fines are 2-4% of global revenue. The previous CEO sold his stock when these issues were discovered.
Let's look at it in a different market: We all know that cars are extremely hackable. Even the Tesla gets hacked (nowadays with great difficulty). The reasons that Auto companies can skate around cyber security is:
1. No car has been hacked in the field by the bad hackers (white hat hackers not included)
2. No one has died.
3. They have cyber insurance.
4. Market doesn't care enough.
5. There are no NHTSA requirements to do so. Guidelines only.
Can someone explain why simple CALEA can't be used to force FB to intercept and relay voice calls when a warrant is produced, please? Is it because it is not an actual PSTN kind of service? Right now, all my calls go over cellular so the govt can intercept it. Or is it that the govt wants to have unrestricted access to all phone conversations?
I know that the US Customs/border have a lot of leeway (a polite way to say that they ignore the Constitution). Would the legal types be able to say if this ruling could be applicable at the US border/Airport/etc. ?
At some point or the other I fully expect them to copy my laptop drive and my phone not because I have super secret documents but because they can.
I have been in security for 20 years and I have come to the following realization:
People will not fix security issues unless there is a penalty (market share drop, people die, lawsuits, recalls, etc.). No one follows SDLC unless there is visible harm or a profit. Even GDPR is not a concern here.
MAC address can be easily spoofed. In fact most Ethernet chips come with the chip manufacturer's MAC ID but once you place it on a device (e.g. a router, camera, etc.) you switch it to the device manufacturer's IDs. It is easy to masquerade ... unless we also have some form of digital signature at the MAC layer. Which would imply that each processor has a private key. There are signature anonymization techniques that would protect the privacy of the device ...
It will be better for IBM to not get its brand-name tainted, all for this silly app. Large corporations, governments, non-profits, etc. rely on IBM to be trustworthy. If they fail, they should just own it, slaughter the culprits, quickly, and move one. The longer they fight it the more they will look like FB. And customers will challenge them all the time. I hav a lot of respect for IBM as an entity and I have worked in security long enough to know that these mistakes occur but one needs to correct the mistakes and move on. I'd have said, 'Oh shit, we will fix it, and here is $20M for your city, used for buying IBM stuff (at full price, and we get a tax break), and lets smile for a photo-op and thanks for helping us. We love you for how you have helped us and make us a better IBM. Thank you.'.
Is there a way we can get a minimalistic PDF reader that just renders stuff. No code execution, no access to local files, etc.? Oh, you mean documents which include other documents? Should be a local file read ... if other software can safely access files Adobe can too.
Adobe seems to have done a good job capturing the market and then doing everything possible to give it away. I once was invited to a security Webinar requiring me to install Adobe Flash. I sent Intel a polite note explaining the problem ...
#5 is completely true; have worked with many Aussies who go into pre-frontal cortex deficient mode when I tell them that govt spying is bad or that the stuff they are proposing will nor work. By using the two trigger words, the govt captures their brains. If you tell them that it is easy to bypass those controls, their usual comeback is, "So you support the terrorists and pedophiles". SMH.
Good point. Compromising the RNG would be bad for the health of ALL crypto. That may be what they may be alluding to. Or push for. They might actually propose Dual_EC_DRBG. Hard for a normal human to test for randomness. I am sure that quantum computing will be put to "good use" when it becomes available. (sarcasm).
Alice and Bob, Aussie and British citizens respectively, each create Elliptical curve key pairs.
Alice and Bob call each other and exchange their public keys.
They then send messages to each other, using ECIES.
Suppose they do rapid ephemeral key exchanges. Would the govt like to keep track of the ephemeral keys too? How many?
Can I generate an ephemeral key every 100 ms or so.
Will the government like to keep track of all the keys?
Programs like Signal: can Dick ban them? How?
Alice’s homeland dictator, Dick, may get overwhelmed.
In general I have associated hyperthreading to imply a large number of threads.
Intel uses 2 threads per core and calls it hyper.
I know companies which have built processes with 64 threads per core.
Threads were really meant, in these systems, for computational separation but not memory isolation. For example, you establish a pipeline of processes that data has to flow through to end up at a socket endpoint.
Intel, at some point, may have pushed this as a mkt advantage, selling ‘more’ cpus than they really had.
Are there many applications that get a performance boost IRL from threading? The requirements for cache coherence is extremely tight. I can think of same instruction same data as the basic requirement.
1.2B per year subsidy, I.e. 48k per year per employee subsidy for the first 4 years. State + city taxes are roughly 12-15k per year. So payroll taxes doesn’t make up for the loss.
I guess it is corporate welfare.
My bet is Jeff Bezos already knew where he wanted his HQ2 but was trying to get a good bargain.
I have seen this argument used many times. The problem is you end up with a Maginot Line effect. Any compromised device on the network can be used to compromise the router. Plus there are ways for JS to initiate a login to the router. So badly implemented browser security can let that happen. The right way to do secure design and implementation is to have security well implemented in ALL components.