Posts by mj.jam 54 publicly visible posts • joined 14 Mar 2019
They always had this clause. If you ever moved to a paid plan, you couldn't go back to free. Meant it was cheaper to pay for the extra pages outside the plan.
They also used to offer special offers on the paid plans, including free months to try to get you not to use the free one.
No, the field notice says not only that you can proactively replace, but they recommend that you do. Obviously you then have to keep your fingers crossed that the current one doesn't fail until it arrives.
Also if your current one does fail, I'm sure shouting at them to get the import stuff done quicker might help. If the only issue is money and taxes then Cisco can eat that cost as well.
I can't imagine replacing all customer units is going to be cheap. The units they get back can't be resold as new.
This is always the trade off between setting a short time, and having to develop the mechanisms for updates in the field, and picking a long date and hoping nobody ever hits it!
I'm guessing the person who used a certificate lasting 10 years is long gone. Then again they probably also didn't think people would still be using the phone 10 years later.
Yes, a skimmer means somebody got something into their website that reported your details to them (as well as to Robert Dyas). Similar to a skimmer over the slot of a cash machine which reads your cards as they are used. Doesn't stop the data being used for the original purpose, but separately reads it.
Typically CCV numbers are not stored by people, so if they are exposed then that would show either they have stored them in their DB (which is very naughty) or that somebody skimmed them on the way.
Zoom has plans going up to 1000 participants. For the amount they are paying, they could get meetings large enough to get everybody in.
It isn't as if they need everybody to be able to host 1000 people at a time. They can get a single Pro license and extend that to 1000 participants.
Even H.323 allowed for cascading of conference bridges, so the 120 limit feels more like they only have to work 1 day in 5.
Worse than that, they don't seem to have data for a few years before 2012 either.
The real problem here is that this is coupled with smoothing over 3 years. Everything shows the decay at the end.
With smoothing turned off there is the raw data at least.
https://books.google.com/ngrams/graph?content=spintronics&year_start=1990&year_end=2018&corpus=15&smoothing=0
Still shows is dropping down, but not as dramatically.
If you read the advisories, it turns out it is different TLV fields in different products. So not a protocol issue, just one parsing long messages, and probably missed size checks when copying fields across into structures. Likely to be different code bases for each product which is why these are all different.
CVE-2020-3110 heap overflow in the parsing of DeviceID type-length-value (TLV)
CVE-2020-3111 stack overflow in the parsing of PortID type-length-value (TLV)
CVE-2020-3118 improper validation of string input from certain fields within a CDP message that could lead to a stack overflow
CVE-2020-3119 stack buffer overflow and arbitrary write in the parsing of Power over Ethernet (PoE) type-length-value
CVE-2020-3120 resource exhaustion DoS
This feels exactly like a backdoor.
I can't imagine that you write this code in any way that is not deliberate.
1. Sending messages to a particular port
2. Encrypting some of the information with a key
3. Checking the response and opening another port.
4. Allowing you to connect to that port using hardcoded credentials
This isn't a "If you send a very long message then you can overflow a buffer" issue, or a "you can trick the authentication system due to it not properly validating input", it is a backdoor used to be able to get access to a system. It may have been put there for debug purposes, or for troubleshooting, but it is not documented. Therefore it is a backdoor.
Cisco has a Technology Verification Service for this sort of thing.
https://blogs.cisco.com/security/introducing-the-cisco-technology-verification-service
https://www.cisco.com/c/en/us/about/trust-center/transparency.html#~tab-tvs
Obviously no idea how easy it is to get in to do the inspection, but I can imagine that most European governments would qualify.
Assuming encryption not hashing, then the answer is easy. Decrypt the password, check the characters provided, return true/false.
If hashing, the problem is actually worse. Even if they hash each combination of 3 characters, then any leakage is trivial to brute force. First 3 characters require 64^3 guesses, and then each additional one requires just 64 (assuming your bank actually allows 64 different characters in your password)
The total of 300 feels like just about enough data for that. Although it depends if they need to do any hyperparameter searching where they would need a third data set. The problem they will run into is that they may keep tweaking their model and using it on the test data set and finding one that works. Or keep repartioning their data until they get something. Everything is likely to be highly over-fitted since all they have done is add a manual phase into this.
mDNS helps a bit, but that only solves the DNS part. You still have to put the domain name in, and the domain still needs to match the certificate if you want to avoid warnings.
Two problems with mDNS.
1. Dodgy support on Android. So for example Chrome on Android doesn't work.
2. It is valid to do both mDNS and DNS for .local domains. You might think this isn't really an issue, but if you have an ISP that changes NXDOMAIN to their ad-filled landing page's IP address, your session to the .local can end up pointing at the wrong place.
The problem here is that it is hard to produce a secure bootstrap that is simple enough for a home user.
You want a dedicated certificate/key pair that is provisioned in the factory per unit and signed by the CA.
However this is tied to a specific domain name. So rather than say "connect to 'routerlogin.com' " you have to say, "connect to the address printed on the label" which will be something like 'SERIAL.routerlogin.com' which (assuming the router is acting as the DNS server) resolves to the IP address of the router.
But then the user has to type in that longer address, they will no doubt get it wrong, or fail to understand the instruction.
You can do it as a QR code or similar but then they need to scan that somehow. Waving their router in front of their laptop webcam isn't easy!
So things like LabelMe from MIT (http://labelme.csail.mit.edu/Release3.0/) could easily fall under this. Basically anybody doing image labelling as part of training will have this sort of capability. All it requires is some work to create the right labels ("Secret military facility", "Launch site", ...) and then the manual work of labelling all the images.
Actually reading the paper in more detail, and looking at the code, the postamble doesn't actually exist, it is just the preamble again for the next data, so any 16 bits contains 6 bits of preamble (and hopefully allows them to take any 16 bits and determine which 10 are interesting)
But the 10 bits are 8 data + 2 parity in the paper, but 8+4 in the example code.
So somewhere around 50% of the bandwidth is overhead. So looks like plenty of room to optimise the framing of data.
I agree, feels like way too much overhead per message. Probably a case of "not invented here" or not looking at what already exists.
Maybe they would be better with 10b8b encoding, and having reserved patterns for start and end. Or even look at serial communications which managed start/stop/parity bits with far less overhead.
Looks like they try connecting back to localhost, but via a somewhat circuitous route.
1. Look up DNS record
2. Get back 127.0.0.1
3. Connect to 127.0.0.1 with server name as above
4. Get presented certificate for that server name. So connection is all ok. (Plus since it is a trusted certificate you avoid all warnings. Just connecting to 127.0.0.1 won't work)
For localhost to be able to use that certificate, it must have the key, i.e. you have the key inside the connector. But not just you, everybody with the app has it.
So if instead you
1. Look up DNS record
2. Get back evil hacker's IP
3. Connect to evil hacker's IP with server name as above
4. Get presented certificate for that server name. So connection is all ok. Isn't it?
Far better for your localhost to have its own certificate, and have the client trust just that. However that takes more work.
Yes, it is exactly that.
They use a whole bunch of regular expressions for this. Just look down the linked article for this beauty.
<text><![CDATA[((?<=^|[\s#,"=\(\[\|\{])(?:1[0123456]|9)\d{8}|^@[\da-fA-F]{16,24})(?:\.?(\d{1,6}))?(?![\d\(])]]></text>
The first '6' is what they have added. Clearly not confident to allow timestamps starting 17 yet...
Typically I print just the signature page, sign that, take a photo on my phone, and send it back. Seems to be fine.
Only one step removed from sending back a whole paper document with you signature on the last page and the freedom to change any of the others at any time.
Why they think that a digital signature is less secure than this I have no idea.
I think the point is more that they don't have any working equipment in space. So until they build and launch a replacement, they have two options.
1. Do nothing, hope that there isn't a major problem
2. See if they can use other data to partially fill-in the gaps they have.
I don't think they are pretending that they will do major advances on the science here, more that they think they can still provide early warning for events.
The birthday problem for this sort of clashes is well studied.
https://en.wikipedia.org/wiki/Birthday_attack
If they did use 128 bit hashes, then the probability of a clash is very low even for billions of images.So I guess that either
1. They really do have billions of hashes, and were just (un)lucky here.
2. Somebody has worked out the algorithm used and manufactured a hash collision.
3. They are using far fewer than 128 bits.
4. This wasn't a hash attack.
Given the combination of account it happened with, and the image that ended up being used, I would tend towards this being something that was done deliberately.
The problem is that people don't want to re-invent the wheel constantly. So reusing somebody else's code makes it simple to build things on top of other components.
The problem comes that people don't review what they are importing, the repositories have no quality control so act as dumping grounds, and then people blindly take updates.
Also people create pointless components that aren't worth using. For example the wonderful is-even:
https://www.npmjs.com/package/is-even
Once again the blindly pulling of third party code causes problems.
The only way to stay secure is to specify a version, and audit all changes.
With Javascript, either use a local copy, or use SRI (or if you are BA, do both)
If building into your own code, then fix the versions, and check and changes.
Boeing say “IOActive reviewed only one part of the 787 network using rudimentary tools, and had no access to the larger system or working environments"
I read "If he had reviewed more parts of the network, and had other tools, then he may have worked out how to jump between the network segments"
But maybe the next phase will be to stop people being able to communicate except with approved providers. Your ISP will be mandated to prevent you sending messages to anywhere else.
Then to finish it off, all providers will need to stop you uploading encrypted content as well. Imagine if people used some sort of encrypted message, sent over email. The horror.
That makes it sound like they were trying to allocate individual header bits to different fields. So 28 bits only would give them 74 hours, but that wasn't enough, and 30 bits gave 300 which would never be needed, so they choose 29 bits.
I guess they then didn't write any test cases for overflow. I can imagine the problem is that they haven't wrapped the comparison operation correctly. So the newest data ends up looking very old.
Any ideas about what is overflowing? 149 hours of seconds doesn't seem to be that obvious a limit, but I guess they probably have rounded down a little to stop planes falling out of the sky.
I've seen issues similar to the Boeing one turn up in less critical places. Found my customers since in internal testing no system was left up for long enough.
Note that the client performs the same authentication procedure as the router. Therefore the side-channel methods also apply to the client. This means that observing the memory access patterns is far more of an issue on the client.
The downgrade attacks also are against the client, not the router. The attacker spoofs the access point, and tells the client that it doesn't support WPA3, so the client tries WPA2.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
