Posts by Ken Hagan 8168 publicly visible posts • joined 14 Jun 2007
"Two weeks ago, the pair received thanks from Intel for working with the company to disclose the bugs responsibility. "
Well, had Intel published all the architectural details about a decade ago, none of this would have been necessary. Someone at Intel took the decision to put this into their chips but not publish how it worked bother to make it secure. (The two versions of that sentence are entirely equivalent to anyone who knows anything about software development.)
And whilst we are on the subject ... I'm told that AMD have a similar feature. Have they documented it? Or are they enjoying Intel's discomfort without realising that the same inexorable logic applies to them.
"because the adslingers would have to understand what "median" means"
No, they wouldn't. They'd just have to pay the penalties until they learned that they should ask someone who does before making public statements on behalf of the company.
The Laws of the Land aren't like the Laws of Nature. Compliance is entirely optional.
Welcome to my world. I'm an application developer and my machines actually belong to my customers and, yes, I'm only allowed to talk to them after the script (my application) has been tested on mock-up systems that don't matter and then signed off by quality control once they demonstrably work.
Why should you have lower standards when the target system belongs to your own company?
"Sure, we had WSH and batch, the languages where "adequate" but they couldn't do anything useful due to the lack of bindings"
Ummm, the lack of bindings is a problem with the thing you are trying to script, not the language you are trying to script from. However, I will agree that the adoption of Powershell *did* give Microsoft developers a strong kick up the arse on the matter of providing such bindings in a more systematic fashion across the system.
"installer and wizards that can create reply scripts to be run in quite mode"
...like a deb, then?
"prefer to write an installer with a proper setup creation tool"
...like a deb, then?
"Even on Linux writing a proper rpm/deb is better than a bunch of ugly scripts."
...so you *have* heard of them, even if you haven't yet grasped the fact that they package, amongst other things, scripts.
They may have got away with it this time, but it isn't a completely sure-fire method of erasing bad publicity. Had they been the subject of a court case rather than an Ofcom complaint, their statement to Google that the reports of the findings in that case were "not true" might be regarded as contemptuous.
@phuzz: Thanks for the clarification, but I'm still puzzled. I mentioned Secure Boot simply because that's the only layer I'm aware of between the OS and the IME. Since the owners of those layers (Microsoft and Intel) appear to be unable to do the job without additional help, it did seem like an intermediate layer might be relevant. I'll have another go at framing my questions and perhaps you or someone else can clarify things.
Who writes the patch? Is it just Intel or do they just explain what needs to change and leave it up to someone downstream? Does that patch depend on the CPU, the chipset, anything else more vendor-specific?
Who distributes the patch? It clearly isn't something that Microsoft can distribute via Windows Update or else Intel could just give them the code. There seems to be a requirement for someone in the middle to be involved EITHER in the authorship (bringing vendor-specific details to the code) or the distribution channel (providing vendor-specific authentication for the code).
How is the patch applied? Does the patch program run instructions at the (regular) OS level that automagically cause the patch to be uploaded to the IME, or does it have to ask an intermediate (such as the UEFI layer) to help with delivery?
An finally, perhaps a little tongue in cheek, if the vulnerability lets someone hi-jack the IME, why can't Intel use the vulnerability to produce a "universal" patch that doesn't need the co-operation of foot-dragging vendors? Less tongue in cheek, I think it is reasonable to assume that *some* people are working on such a thing, even if Intel aren't.
This situation smacks of the Android universe, where the author of the offending software has to rely for patch incorporation on the hardware vendor who in turn has to rely for deployment on phone operators. It leads to woeful security in practice because patches are never deployed and everyone blames everyone else. In the PC case, I'd have thought that the hardware vendor was Intel itself (or, worst case, a handful of motherboard UEFI BIOS providers) and there simply is no equivalent to the "phone operator", so ...
What have the PC vendors actually done to insert themselves into the critical path?
How could the system be changed fixed to remove them?
"Once you have the market a 'from the ground up, yet compatible' replacement that still allows the mass data collection without providing a 'free' platform for your rivals to capitalise on seems to make sense."
If it is compatible, there's no reason for developers to write apps solely for the new platform or for consumers to buy your phones rather than those of vendors who are now your direct competitors. If it is not fully compatible, you may just find that all the other vendors continue to run with something more AOSP-like and make a big point about "compatibility" in their advertising.
I'm not sure how Google expect to ever make money out of "controlling" a phone platform when even MS have discovered that unless you are also fully compatible with a platform that you don't (and cannot) control, you can't sell the kit.
Aren't we talking about public places here and haven't amateur photographers been trying to persuade police that taking pictures of things that are in public is OK? That would mean we are arguing about whether it is OK to automate something that is perfectly legal to do manually (and whether the automated version is more or less reliable than the manual version).
As the US Constitution acknowledges, there are reasons to worry about, and limit, the power of the state more than we worry about the same powers in the hands of lesser actors, but we should be clear that *this* is our objection rather than a Luddite objection to the economies of scale.
See https://blogs.technet.microsoft.com/windowsitpro/2017/07/27/waas-simplified-and-aligned/
Microsoft's current position is that they have four versions of Windows on the go: Insider, Targetted, Semi-Annual and LTS. The last of these is only available if you are an enterprise customer and I'd be surprised if the average SME is so I'll ignore it.
The Semi-Annual was formerly known as Current Branch for Business and is what you ought to be running (even if you are a home user, IMO). *Someone* in your organisation should have a few machines on the Targetted channel, to try to flush out issues like this. (That said, where the issue is a cock-up rather than an intentional withdrawal of a feature, it isn't obvious whether the more stable channel is actually a safer bet.) Microsoft themselves also recommend that any developers in your organisation should have a few machines on the Insider channel, to get even more advance warning of crap to come.
You *could* start looking at whether your software requirements could be met by a platform that wasn't so incredibly user-hostile, but I think we all know the issues there. The bottom line is that if you *have* to use Windows, then you *ought* to be jumping through the above hoops.
"Perhaps it's also time they were required to carry insurance?"
The case for compulsory insurance is that motorists can and do kill people when it goes pear-shaped. That's also the reason that only third-party insurance is compulsory.
Cyclists tend not to kill people when they get it wrong, in the same way that pedestrians don't. I'm sure you can find counter-examples of both, but the numbers are so insignificant that society doesn't feel there is a problem to be addressed.
"Edge was supposed to be the secure and rewritten new browser, without the tons of bloat IE was affected with."
Dunno where you got that idea from. My recollection is that MS described Edge as "IE but with all of the compatibility code taken out, so it *only* handles pages written to the HTML5 standard". I'm not sure if that was actually true, but it was a fairly plausible thing to try and Edge certainly didn't include support for a lot of old stuff like ActiveX and MHTML so I've no reason to doubt it.
"I've yet to see a mathematical proof that useful features of programming languages are necessarily also undesirable, but experience suggests a strong correlation."
Perhaps I can help. It's not strictly mathematical, but I can offer a good reason for this.
Nearly all language designers have opinions about good practice and their languages reflect that, making it easy to do the right thing and hard to do the wrong thing. Many languages make it extremely hard to do the wrong thing. (Google for "bondage and discipline", but in the context of languages rather than sex.)
However, language design is not a science and so eventually there is a real-world need for some sort of get-out-of-jail-free card to let you get the job done. Fortran has its COMMON blocks. C has its unions. C++ has its C-compatible base. Assembly language has self-modifying code. Pascal has ... linker compatibility with libraries written in a proper language.
Any sufficiently large programming project will end up playing this card.
"If you're living in the west, _you_ are part of the 1%."
Interesting take on basic arithmetic you have there. At least half a billion people live in Western Europe and North America, which is nearer 7% of the world population. This is without adding in places like Japan which are not geographically "west" but certainly belong to the western economic model.
The converse is not true either. Quite a few of the world's 1% are despotic scum who have screwed their respective countries for decades.
"The facts are as stated - the software they need mostly doesn't exist on Linux"
Whilst I would agree with your point that it isn't *their* job to evangelise Linux but rather to get their work done, I would draw your attention to this bit in the article:
"mail servers, for instance, eventually wound up migrating to Microsoft Exchange"
Really? Bluntly, if you can't even get an email server running, either nobody is trying or there are people in your organisation working behind the scenes to sabotage the whole endeavour. It seems unlikely that no-one in an organisation that large had the skills necessary to get a server up and running, so the only reasonable conclusion is a fifth column.
Amazon will sell you a used Samsung S5 in good nick for considerably less than 200 quid. (Other tat-vendors are available...) The S5 is one of the most widely used phones with Lineage (https://www.lineageoslog.com/statistics) so it won't just be you if something goes wrong. You don't have to root the phone (https://wiki.lineageos.org/devices/klte/install). If you are particularly doubtful of the procedure, you could try it on an even older phone. The S4 Mini is about a third of the price and also works OK.
I'm citing these two Samsungs because I've actually done it with them. (I haven't looked back.) It shouldn't be taken as an endorsement of Samsung. (I put Lineage on because Samsung's support was so crap.) A glance at the stats will show that other brands also have thousands of users out there and your current handset may even be among them.
Edit: If you do switch, give some thought to how you will transfer things like address books and saved media/messages/etc. Mostly these aren't terribly difficult as long as you plan ahead but are obviously nigh-on impossible after you've nuked the old contents of your storage. :)
Throw the code together, No testing or ignored testing. Ship it.
It makes economic sense, right up to the point where your customers, en masse, decide that you are taking the piss with the $1000 price tag and decide to Switch Brand, at which point your company has its Ratner Moment.
So, yeah, consider this a *big* heads-up for shareholders: a computer that can't spell its own name.
To enlarge on Alan's comment, where a system asks for both a complete password (which can be hashed and salted) and a few characters from a second set (which probably can't) the point of the second line of defence is that you will be asked for a different selection the next time you log in. This hardens the system against keyloggers on the customer's device because for any reasonable length of the second set, it will be quite a while before the same three are asked for.
"My reason was that you could fit the whole system into ~6KBytes (6809) including (simple) disk i/o."
That would make it a fine language to compile into. It says nothing about whether human beings should be forced to write in that language to begin with.
I've used several languages (Forth and the wretched NSIS setup scripting lingo spring to mind) that would have benefitted from an afternoon's work with yacc/lex to put a pleasant syntax on the front. The same goes, incidentally for some command-line tools I could name, whose options take about 20 screenfuls of man-page to describe.
No. You are the kind of doofus that the feature is designed to obstruct. A computer wiz would have provided sufficient evidence to their sysadmin that the handy little photo editor was legit and should be added to the whitelist.
In the meantime, you've created a nice little sandbox called Documents2 and when you next download some ransomware it will only be that sandbox that gets toasted. "Documents" will be fine.
This is the stuff that Dave Cutler brought to the party, 25 years ago. I've seen various ways of getting the configuration wrong, but I've never seen the configuration not being enforced properly.
If you are a big fan of the original UNIX model then you can stick to that subset, although UNIX doesn't anymore so perhaps it wasn't quite so great.
I don't know, but if I were asked to implement such a feature then here's how I'd do it.
Windows access control already understands the notion of high, medium and low "integrity". That is, whether a piece of code (rather than the user) is trustworthy. This is how they implement UAC. So, on each of the directories that you want to protect, you add a access control entry (ACE) denying write access to some lowly level of integrity.
Window Defender then hooks into the module loader and arranges that each new process has that lowly level of integrity (in its process token) unless it was whitelisted. It also hooks DLL loading so that adding an untrusted DLL to a trusted process changes the integrity level. (Small loophole there: if you've opened a file and then load the library, you probably still have access via that handle. Perhaps someone at MS has written the additional code required to close that loophole.)
The result is that most processes only have read access to Desktop and Documents (or wherever) but a few whitelisted processed have write access. Enforcement is via the tried and trusted (for 25 years) mechanism of validating access of tokens against lists of ACEs.
Update: I should probably state explicitly that although the usual situation is for all processes that run "as you" to have "your" credentials, the Windows kernel is quite happy to juggle with different versions of "you" and access control is actually done based on the identity (token) of each process.
"Will hijack your browser or Outlook or some other whitelisted application and use it to encrypt your folders. "
You have posted this in reply to a comment that Outlook wasn't one of the whitelisted apps.
Presumably the whitelisted apps have to be digitally signed and will lose their white-listing if they import DLLs that aren't also approved. There's no reason why this can't be made watertight. It doesn't look to be using anything that hasn't been part of the Windows kernel for about a decade. Having said that, I will grant you that whether it is actually effective is another matter.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
