When the kernel enters the BSOD/crash routine, nothing is guaranteed to be safe. The stuff that was pre-allocated and set aside? Not safe.
Incorrect. Any memory that has been marked as read-only can absolutely be considered safe. Indeed, the STOP condition may have been caused by some process or the kernel attempting to write such memory. So if the OS marks its core memory (code, jump tables etc) as readonly after loading, those jumptables and that code can absolute be assumed to be safe.
How does a CPU "know" where the QR code routines are at? By a jump table full of pointers to locations in RAM
No, initialized pointer to jump table sitting in readonly memory pages.
I have seen computers crash so hard that they could not even spit out their error message and the result of trying was to do some nasty things with the floppy disk controller.
Obviously that can happen. If the graphics card misbehaves, attempts to use the screen could fail miserably. Likewise with disk controllers.
That not the point, though. The point is what *extra* assumptions generating QR codes makes about what components are still safe to use. If QR code generation makes further assumptions, then yes, it could be a problem. But as it stands, the STOP handling code already uses the screen (error message) and disk (dump to pagefile). If coded correctly (engineered for failure) it makes no further assumptions and thus does not increase any risk.
It's like you and GP totally ignore the most basic principles of OS design and common engineering principles. No, I have not seen MS's code and cannot claim that they make no further assumptions about heap, device drivers etc. But cannot the the reverse either. I *assume* that they are more competent than you and GP, however, and make good use of read-only memory.
Now some dip shit from marketing wants to put a 100% worthless QR code on the screen. Thats something that has to be calculated. That means intentionally doing more computations on an unstable system and ignoring all conventional wisdom. The QR code provides no benefit and adds risk.
Why do you think it's a marketing idea?
There is absolutely no reason the QR code could not be calculated without additional risk. If the space has been set aside, the kernel thread has it's own "safe" space for the stack (which it must have since also creating a dump in the swap file requires at least some call instructions). You can absolutely work out in advance how much has to be set aside for the QR code and -computation. Just like with the minidump.
Now, what could be the upside? While the QR code cannot contain the minidump itself, it can absolutely contain register values along with the program pointer and the module/device driver (name, version, vendor etc) it was in when the STOP error occurred. That is enough to provide a really valuable service once the user hits the web page through the QR code. A known problem with a faulty device driver can for example direct the user to a later/fixed driver, to boot in safe mode or otherwise uninstall it. It will also provide valuable information to Microsoft/3rd party vendor as to the number of computers experiencing a specific problem.
That is engineering - as in engineering for failure - not marketing.
Or worse still, probably some jackass in the phone group decided that crashes should have a QR code so they could sell phones with QR readers to admins.
Like, I don't know, say, a system log that would store messages from drivers and system components like dmesg?
How about a memory dump before crashing that can be inspected later?
What makes you think that Windows does not store messages and does not create a dump (hint: it does. Stop errors are logged in the system log, and default is to create a dump file upon a stop error. Space is even reserved for the dump file on the system drive to guarantee that a dump can be created even if disk is full).
But hey, why don't you make your own assumptions and go by them to diss on something that you obviously don't know anything about?
When you restart your computer, Windows will recognize the dump file and will offer you to upload it to Microsoft. In case of device driver crashes (the most common cause along with hw fails) Microsoft will even notify the vendor if they have registered for crash information.
Or are they saying it WILL have ads? I've never seen any.
Summary is misleading. Outlook does not have ads, and never had. outlook.com does have ads in the free version. outlook.com is a hosted email solution. You can use it through the web interface or any other email reader - including Outlook (the application).
Unless Microsoft comes with a deal with Here Maps, most consumers will shun Windows Phone.The major option available seems to be Bing Maps; is that good enough?
For Windows 10 (both the phone and the desktop editions) there is the Map UWP app. It is actually based on HERE technology licensed by MS. The HERE apps have never been available for Windows 10 - although they would follow along with an upgrade.
IMO the Map UWP app is actually better: It has all of the functionality of all of the HERE apps, but integrated into a single app. It has tremendous 3D maps, turn-by-turn navigation, downloadable maps, public transportation planner etc.
While the HERE apps were quite good, I don't think anyone will miss them when they realize that the Map app is actually the quivalent of all of the HERE apps.
No. That is, there might be, but the blog post is not about the discovery of a vulnerability.
or are we just saying software can have bugs and that people will try to exploit those bugs?
Yes, pretty much. The slashdot submission actually tries to spin the message of blog post around: Reading the post, the researcher seems to be of the opinion that even with a vulnerability in the PDF library of WinRT - especially with Control Flow Guard protection in Windows 10 - is actually very, very hard to exploit. Not exactly what you read from the submission.
And it makes sense too: A PDF library developed under Secure Development Lifecycle (SDL) is likely to have *fewer* vulnerabilities than age-old adobe code. Firefox approach (PDF renderer exclusively in JavaScript) is somewhat better, but does not allow for the functionality to be used in standalone applications.
Just send all the Muslim refugees to college for free.
Oh, we will. You can count on it.
If they are accepted as refugees, after a few years they will be eligible for the same benefits as other citizens. Danish education - including college education - is free. Not only that, but we will even pay students scolarships of around DKK 5100 a month (apx $9200 per year) to cover living costs.
Universities have admission criteria, however. You'll have to be accepted. Most citizens with muslim background seeking higher education tend to go for the types of education that traditionally have high status in their culture: Law, medicine, dentists etc.
I have a high wage. I pay a *lot* of taxes. Do I mind that refugees seek education in Denmark and receive benefits? No, I do not. Any qualified young man or woman seeking higher education is *exactly* what we need. If they're qualified, I'm happy with paying my taxes so that they can receive an education even if they come of circumstances very unlike mine.
Right now we're receiving both refugees and migrants. We are well aware that the generous welfare systems in the Nordic countries and the economic opportunities (and welfare system) in Germany is attractive. Obviously, the Nordic countries cannot open the borders and let in every needy person in the world.
Bit the ones we *do* let in considered needy. And they *will* be eligible for the same benefits as the rest of us. And I'm kind of proud of that. And yes, I pay my high taxes with pleasure. Makes me feel good about it.
The Nordic welfare states are dropping like flies.
Eh? By "the Nordic welfare states" I'm assuming you mean Denmark, Sweden, Norway, Finland?
Let's examine that claim. Sweden is doing great, Denmark almost as great. Norway has the oil (and a *lot* of it) and has had the god foresight to save oil money from the good times to insulate against poorer times. Norway is doing exceptionally great. Which leaves Finland. Sure, Finland has challenges which can be attributed to a disrupted monoculture. But they are not dismantling the welfare state by any means. They're innovating. None of the Nordic countries are about to "drop" like a fly.
I don't know why you would try to paint a picture of the Nordic welfare states failing. They're not. Not by any stretch of imagination. Do you live in a place where successful welfare states would be an inconvenient counterpoint to your political point of view?
Yes - there's challenges in the Nordic elfare systems, like with any other model. Right now the Nordic welfare states (and the German welfare state) are under pressure because a lot of migrants would like to live in a place with generous social benefits, free education (and at least in Denmark you will even receive full state-paid scholarship all the way through college), free healthcare, retirement welfare etc.
Other countries have other challenges. In the US the average middle-class income has stagnated sinde the 1970ies. The wealthy are getting wealthier, the middle-class is struggling and the poor has gotten even more poor. US social mobility has degraded to a level where "the American dream" is but a distant fantasy.
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
On Windows, uninstallers cannot delete system files. Since Vista, Windows Resource Protection has prevented even processes running as administrator or SYSTEM from changing/deleting system resources (files, registry keys etc). Only the "trusted installer" account can write those files, and only the WindowsUpdate process runs as trusted installer. It will not install 3rd party applications.
Not saying that an uninstaller cannot do other harm which could toast the boot process, but it cannot delete system files. Safe mode will trust *only* system files, and should always be able to load - bar hardware failures.
I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.
You can not accidentally write to those variables in Windows when trying to format a disk or do other admin work.
The problem is that systemd has put those variables directly in harms way. *Never* would you expect that removing all files from a file system would delete variables outside the operating system - in the firmware.
The file system is *owned* by the operating system, which is a subordinate of the firmware. The control chain goes: firmware > boot-loader > operating system > file system. For the file system to cause damage to the firmware is a design bug, even if the endpoints to do such damage has been exposed by the firmware.
The mental model of a file system - the expected behavior - is for it to be hierarchical. We silently expect anything below a certain path to be subordinate. Already this model is broken because devices can be mounted, files symlinked/hardlinked etc. That something much more fundamental to a system than a file system directory can be found deep in the hierarchy is a violation of the hierarchy.
That's why it is surprising that removing everything from the file system may cause higher order information to be deleted as well. You do not expect that. The impulse to map everything to a file deep in the filesystem is dangerous.
Sure, you can probably write/destroy UEFI variables from windows, but not as unintentional collateral damage from deleting a directory.
But is it really an upgrade? Doesn't the MS installer just installs a clean XP next to 98 and renames the Windows folder to Windows.old?
Yes, it is upgrades: The Windows.old directory is for safe-keeping. The OS itself has been upgraded. True, in the case of 98 => XP it means replacing everything. But an OS is tasked with managing hardware devices and running applications. All relevant settings as well as compatible applications are carried over thanks to the registry (yes, the registry!). User files and data moved to the correct locations.
The updates to telemetry do not suddenly cause Windows to start sending information back to Microsoft. Only when the user has explicitly accepted CEIP (Customer Experience Improvement Program) will these updates have any effect on a system.
If you have not activated CEIP, the updates will not cause any information to be sent back to Microsoft. It is that simply.
Nothing to do with java. Buffer overflows are quite possible with java, but this problem has everything to do with shitty coding, not the implementation language.
No, but this problem has everything to do with shitty operating system design. The login "screen" should not just be an application that maximizes it's screen to cover the UIs of all other application. That is a naïve implementation, and it opens the supposed security feature up to all kinds of attacks, including shatter attacks and more. Not to mention that an application crash will cause the OS to clean up and close the "blocking" window.
Google should take a cue from Windows and make the login screen a totally separate "desktop" which is completely isolated from the "user" desktop. Switching between the two should be a privileged operation, one that can only be executed by trusted login applications. This way a mere exception will not cause the "login" program to crash, close and reveal the user desktop.
It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.
Sorry, but that is not isolation. If the prompt require a password rather than just an accept, the launching process can *still* control it remotely through Applescript - it would just not know what to put in the fields. That's not isolation. At best, it is a mitigating factor.
Isolation would mean that any Applescript launched from the process was *barred* from interacting with the approval window.
The vulnerability here is architectural: Windows can be remotely controlled. Ask yourself this: What good is an approval window, if the process can just remote control the approval itself?
On OS X, this programmatically easier to do, but it's possible with a little more effort in Linux (if using GNOME or KDE and their password stores) and Windows (which is trickiest of all since you specifically deal with an application's store rather than a central one; presumably you'd go for a browser)
On Windows - unlike on OS X and Linux - there is the concept of User Interface Privilege Isolation (UIPI) where a process running with a higher integrity level cannot be remote controlled by a lower-integrity process.
The real vulnerability here is NOT whether the user has allowed the process to run or not or whether it came through the app store nor not. The critical vulnerability is the lack of isolation of the window that is supposed to obtain approval from the interactive user. This lack of isolation means that an OS X application can launch an action that requires approval and then immediately - through script - approve the action itself.
Pointing to the app store approval model is missing the point entirely. Even approved applications can (and do!) contain vulnerabilities. The reason why so many apologists are out in force and try deflecting the problem as "app approval" is because this illustrate an architectural problem within OS X: Even though the same user runs a number of processes, a mechanism for policing what they can do to each other is lacking.
As of Windows 10 (and soon previous versions with Windows Management Framework 5.0) there *is* a default one: OneGet - now just called "package manager". It is controlled through a PowerShell module. It is actually a package manager umbrella, as it can be used for a number of different package managers which can provide "providers" for PM and integrate that way.
Open a PowerShell prompt and type the following to reveal the commands of the PackageManager module
gcm -mod PackageManagement
(or type gcm -m pack[tab] if you want to save keystrokes - powershell will autocomplete the module name)
To register Chocolatey as a package source (so that you can find packages through Find-Package) type this:
When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage? Even 'ancient' Linuxs only add the first user to sudoers so that they have to explicitly invoke rootly powers.
Unlike Linux, Windows uses proper security tokens. Each process has it's own token governing what it can do to which resources. On Linux the "token" is - rather naively - a user id.
When you log on to Windows - since Vista - with an account with administrative rights, thee token that is created for the shell process is 1) stripped of all administrative rights and 2) given an integrity level of "normal". Integrity levels are also part of the token.
What it means is that *even when you log on as an administrator* you do not possess any administrative or god-like rights. You are a standard user.
When you invoke a program that has a manifest which states that it requires some form of administrative rights, Windows will prompt you for "elevated" privileges. Only when you accept to use your administrative privileges will the process be started with a token with higher than standard user rights.
It really is a much more elegant solution than the stupid effective user in Linux, where the description of a process rights is strongly tied to a user: There must exist a user with the specific sets of rights you want the process to have. Not so on Windows: Any process can have it's own token with fewer or more rights/privileges.
You can turn off UAC (don't!), which is why Microsoft must write the disclaimer *If the current user is logged on with administrative user rights*. If you turn off UAC and log in with an administrative account - then you run all processes with full permissions/privileges.
When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage?
They did fix it. You are just ignorant.
How many of these problems could be mitigated if this were not MicroSoft's default approach?
The answer is 92% - and it is mitigated by default.
Slashdot Mirror
Anything that connects to the display (and keyboard and mouse or other SHARED input/output device by implication) needs to be trusted.
That's true in Windows and Linux and Unix and IBM mainframes and on and on.
Oh, and it'll be JUST AS FUCKING TRUE ON WAYLAND - THAT BENIGHTED SOLUTION IN SEARCH OF A PROBLEM.
Guess they'll have to reinvent User Interface Privilege Isolation. Don't hold your breath, though.
When the kernel enters the BSOD/crash routine, nothing is guaranteed to be safe. The stuff that was pre-allocated and set aside? Not safe.
Incorrect. Any memory that has been marked as read-only can absolutely be considered safe. Indeed, the STOP condition may have been caused by some process or the kernel attempting to write such memory. So if the OS marks its core memory (code, jump tables etc) as readonly after loading, those jumptables and that code can absolute be assumed to be safe.
How does a CPU "know" where the QR code routines are at? By a jump table full of pointers to locations in RAM
No, initialized pointer to jump table sitting in readonly memory pages.
I have seen computers crash so hard that they could not even spit out their error message and the result of trying was to do some nasty things with the floppy disk controller.
Obviously that can happen. If the graphics card misbehaves, attempts to use the screen could fail miserably. Likewise with disk controllers.
That not the point, though. The point is what *extra* assumptions generating QR codes makes about what components are still safe to use. If QR code generation makes further assumptions, then yes, it could be a problem. But as it stands, the STOP handling code already uses the screen (error message) and disk (dump to pagefile). If coded correctly (engineered for failure) it makes no further assumptions and thus does not increase any risk.
It's like you and GP totally ignore the most basic principles of OS design and common engineering principles. No, I have not seen MS's code and cannot claim that they make no further assumptions about heap, device drivers etc. But cannot the the reverse either. I *assume* that they are more competent than you and GP, however, and make good use of read-only memory.
Now some dip shit from marketing wants to put a 100% worthless QR code on the screen. Thats something that has to be calculated. That means intentionally doing more computations on an unstable system and ignoring all conventional wisdom. The QR code provides no benefit and adds risk.
Why do you think it's a marketing idea?
There is absolutely no reason the QR code could not be calculated without additional risk. If the space has been set aside, the kernel thread has it's own "safe" space for the stack (which it must have since also creating a dump in the swap file requires at least some call instructions). You can absolutely work out in advance how much has to be set aside for the QR code and -computation. Just like with the minidump.
Now, what could be the upside? While the QR code cannot contain the minidump itself, it can absolutely contain register values along with the program pointer and the module/device driver (name, version, vendor etc) it was in when the STOP error occurred. That is enough to provide a really valuable service once the user hits the web page through the QR code. A known problem with a faulty device driver can for example direct the user to a later/fixed driver, to boot in safe mode or otherwise uninstall it. It will also provide valuable information to Microsoft/3rd party vendor as to the number of computers experiencing a specific problem.
That is engineering - as in engineering for failure - not marketing.
Or worse still, probably some jackass in the phone group decided that crashes should have a QR code so they could sell phones with QR readers to admins.
Ok. Is your tinfoil hat a bit tight?
Like, I don't know, say, a system log that would store messages from drivers and system components like dmesg?
How about a memory dump before crashing that can be inspected later?
What makes you think that Windows does not store messages and does not create a dump (hint: it does. Stop errors are logged in the system log, and default is to create a dump file upon a stop error. Space is even reserved for the dump file on the system drive to guarantee that a dump can be created even if disk is full).
But hey, why don't you make your own assumptions and go by them to diss on something that you obviously don't know anything about?
When you restart your computer, Windows will recognize the dump file and will offer you to upload it to Microsoft. In case of device driver crashes (the most common cause along with hw fails) Microsoft will even notify the vendor if they have registered for crash information.
https://tech.slashdot.org/stor...
Or are they saying it WILL have ads? I've never seen any.
Summary is misleading. Outlook does not have ads, and never had. outlook.com does have ads in the free version. outlook.com is a hosted email solution. You can use it through the web interface or any other email reader - including Outlook (the application).
I may have been misinformed, but they did make the suite excessively cheap and had lawsuits for monopolization for a while because of it.
You need to support that claim. Office was always excessively expensive. It was, and remains, one of their cash cows
Unless Microsoft comes with a deal with Here Maps, most consumers will shun Windows Phone.The major option available seems to be Bing Maps; is that good enough?
For Windows 10 (both the phone and the desktop editions) there is the Map UWP app. It is actually based on HERE technology licensed by MS. The HERE apps have never been available for Windows 10 - although they would follow along with an upgrade.
IMO the Map UWP app is actually better: It has all of the functionality of all of the HERE apps, but integrated into a single app. It has tremendous 3D maps, turn-by-turn navigation, downloadable maps, public transportation planner etc.
While the HERE apps were quite good, I don't think anyone will miss them when they realize that the Map app is actually the quivalent of all of the HERE apps.
Is there an actual bug in EDGE's PDF viewer, or are we just saying software can have bugs and that people will try to exploit those bugs?
In a word, "yes".
No.
Is there an actual bug in EDGE's PDF viewer
No. That is, there might be, but the blog post is not about the discovery of a vulnerability.
or are we just saying software can have bugs and that people will try to exploit those bugs?
Yes, pretty much. The slashdot submission actually tries to spin the message of blog post around: Reading the post, the researcher seems to be of the opinion that even with a vulnerability in the PDF library of WinRT - especially with Control Flow Guard protection in Windows 10 - is actually very, very hard to exploit. Not exactly what you read from the submission.
And it makes sense too: A PDF library developed under Secure Development Lifecycle (SDL) is likely to have *fewer* vulnerabilities than age-old adobe code. Firefox approach (PDF renderer exclusively in JavaScript) is somewhat better, but does not allow for the functionality to be used in standalone applications.
Just send all the Muslim refugees to college for free.
Oh, we will. You can count on it.
If they are accepted as refugees, after a few years they will be eligible for the same benefits as other citizens. Danish education - including college education - is free. Not only that, but we will even pay students scolarships of around DKK 5100 a month (apx $9200 per year) to cover living costs.
Universities have admission criteria, however. You'll have to be accepted. Most citizens with muslim background seeking higher education tend to go for the types of education that traditionally have high status in their culture: Law, medicine, dentists etc.
I have a high wage. I pay a *lot* of taxes. Do I mind that refugees seek education in Denmark and receive benefits? No, I do not. Any qualified young man or woman seeking higher education is *exactly* what we need. If they're qualified, I'm happy with paying my taxes so that they can receive an education even if they come of circumstances very unlike mine.
Right now we're receiving both refugees and migrants. We are well aware that the generous welfare systems in the Nordic countries and the economic opportunities (and welfare system) in Germany is attractive. Obviously, the Nordic countries cannot open the borders and let in every needy person in the world.
Bit the ones we *do* let in considered needy. And they *will* be eligible for the same benefits as the rest of us. And I'm kind of proud of that. And yes, I pay my high taxes with pleasure. Makes me feel good about it.
The Nordic welfare states are dropping like flies.
Eh? By "the Nordic welfare states" I'm assuming you mean Denmark, Sweden, Norway, Finland?
Let's examine that claim. Sweden is doing great, Denmark almost as great. Norway has the oil (and a *lot* of it) and has had the god foresight to save oil money from the good times to insulate against poorer times. Norway is doing exceptionally great. Which leaves Finland. Sure, Finland has challenges which can be attributed to a disrupted monoculture. But they are not dismantling the welfare state by any means. They're innovating. None of the Nordic countries are about to "drop" like a fly.
I don't know why you would try to paint a picture of the Nordic welfare states failing. They're not. Not by any stretch of imagination. Do you live in a place where successful welfare states would be an inconvenient counterpoint to your political point of view?
Yes - there's challenges in the Nordic elfare systems, like with any other model. Right now the Nordic welfare states (and the German welfare state) are under pressure because a lot of migrants would like to live in a place with generous social benefits, free education (and at least in Denmark you will even receive full state-paid scholarship all the way through college), free healthcare, retirement welfare etc.
Other countries have other challenges. In the US the average middle-class income has stagnated sinde the 1970ies. The wealthy are getting wealthier, the middle-class is struggling and the poor has gotten even more poor. US social mobility has degraded to a level where "the American dream" is but a distant fantasy.
You can't do the same thing in OS X. I don't know about Windows.
Windows has had Resource Protection since Vista. Even before that, Windows File Protection going back to Windows 2000.
Only Windows Update can run as "Trusted Installer" - and only trusted installer is allowed to replace or change system files.
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
On Windows, uninstallers cannot delete system files. Since Vista, Windows Resource Protection has prevented even processes running as administrator or SYSTEM from changing/deleting system resources (files, registry keys etc). Only the "trusted installer" account can write those files, and only the WindowsUpdate process runs as trusted installer. It will not install 3rd party applications.
Not saying that an uninstaller cannot do other harm which could toast the boot process, but it cannot delete system files. Safe mode will trust *only* system files, and should always be able to load - bar hardware failures.
I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.
You can not accidentally write to those variables in Windows when trying to format a disk or do other admin work.
The problem is that systemd has put those variables directly in harms way. *Never* would you expect that removing all files from a file system would delete variables outside the operating system - in the firmware.
The file system is *owned* by the operating system, which is a subordinate of the firmware. The control chain goes: firmware > boot-loader > operating system > file system. For the file system to cause damage to the firmware is a design bug, even if the endpoints to do such damage has been exposed by the firmware.
The mental model of a file system - the expected behavior - is for it to be hierarchical. We silently expect anything below a certain path to be subordinate. Already this model is broken because devices can be mounted, files symlinked/hardlinked etc. That something much more fundamental to a system than a file system directory can be found deep in the hierarchy is a violation of the hierarchy.
That's why it is surprising that removing everything from the file system may cause higher order information to be deleted as well. You do not expect that. The impulse to map everything to a file deep in the filesystem is dangerous.
Sure, you can probably write/destroy UEFI variables from windows, but not as unintentional collateral damage from deleting a directory.
It's worth noting that, according to ex-kernel hacker Matthew Garrett, you can achieve the same bricking using a 20 line program in Windows.
You mean to say that if I accidentally type that 20 line program on Windows, compile it, type the name and hit Enter, my box is toast? That's scary!
Thanks for the warning. I'll be wary of those 20 lines. What were they again, just so that I do not type them accidentally?
But is it really an upgrade? Doesn't the MS installer just installs a clean XP next to 98 and renames the Windows folder to Windows.old?
Yes, it is upgrades: The Windows.old directory is for safe-keeping. The OS itself has been upgraded. True, in the case of 98 => XP it means replacing everything. But an OS is tasked with managing hardware devices and running applications. All relevant settings as well as compatible applications are carried over thanks to the registry (yes, the registry!). User files and data moved to the correct locations.
The updates to telemetry do not suddenly cause Windows to start sending information back to Microsoft. Only when the user has explicitly accepted CEIP (Customer Experience Improvement Program) will these updates have any effect on a system.
If you have not activated CEIP, the updates will not cause any information to be sent back to Microsoft. It is that simply.
https://support.microsoft.com/...
Yet its still better than anything that Microsoft can come up with.
System Integrity Protection is akin to Windows Resource Protection - which has been in Windows since Vista. Welcome to 2006.
Nothing to do with java. Buffer overflows are quite possible with java, but this problem has everything to do with shitty coding, not the implementation language.
No, but this problem has everything to do with shitty operating system design. The login "screen" should not just be an application that maximizes it's screen to cover the UIs of all other application. That is a naïve implementation, and it opens the supposed security feature up to all kinds of attacks, including shatter attacks and more. Not to mention that an application crash will cause the OS to clean up and close the "blocking" window.
Google should take a cue from Windows and make the login screen a totally separate "desktop" which is completely isolated from the "user" desktop. Switching between the two should be a privileged operation, one that can only be executed by trusted login applications. This way a mere exception will not cause the "login" program to crash, close and reveal the user desktop.
It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.
Sorry, but that is not isolation. If the prompt require a password rather than just an accept, the launching process can *still* control it remotely through Applescript - it would just not know what to put in the fields. That's not isolation. At best, it is a mitigating factor.
Isolation would mean that any Applescript launched from the process was *barred* from interacting with the approval window.
The vulnerability here is architectural: Windows can be remotely controlled. Ask yourself this: What good is an approval window, if the process can just remote control the approval itself?
On OS X, this programmatically easier to do, but it's possible with a little more effort in Linux (if using GNOME or KDE and their password stores) and Windows (which is trickiest of all since you specifically deal with an application's store rather than a central one; presumably you'd go for a browser)
On Windows - unlike on OS X and Linux - there is the concept of User Interface Privilege Isolation (UIPI) where a process running with a higher integrity level cannot be remote controlled by a lower-integrity process.
The real vulnerability here is NOT whether the user has allowed the process to run or not or whether it came through the app store nor not. The critical vulnerability is the lack of isolation of the window that is supposed to obtain approval from the interactive user. This lack of isolation means that an OS X application can launch an action that requires approval and then immediately - through script - approve the action itself.
Pointing to the app store approval model is missing the point entirely. Even approved applications can (and do!) contain vulnerabilities. The reason why so many apologists are out in force and try deflecting the problem as "app approval" is because this illustrate an architectural problem within OS X: Even though the same user runs a number of processes, a mechanism for policing what they can do to each other is lacking.
But not a system default one.
As of Windows 10 (and soon previous versions with Windows Management Framework 5.0) there *is* a default one: OneGet - now just called "package manager". It is controlled through a PowerShell module. It is actually a package manager umbrella, as it can be used for a number of different package managers which can provide "providers" for PM and integrate that way.
Open a PowerShell prompt and type the following to reveal the commands of the PackageManager module
gcm -mod PackageManagement
(or type gcm -m pack[tab] if you want to save keystrokes - powershell will autocomplete the module name)
To register Chocolatey as a package source (so that you can find packages through Find-Package) type this:
register-packagesource -Name chocolatey -Provider PSModule -Location http://chocolatey.org/api/v2/
When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage? Even 'ancient' Linuxs only add the first user to sudoers so that they have to explicitly invoke rootly powers.
Unlike Linux, Windows uses proper security tokens. Each process has it's own token governing what it can do to which resources. On Linux the "token" is - rather naively - a user id.
When you log on to Windows - since Vista - with an account with administrative rights, thee token that is created for the shell process is 1) stripped of all administrative rights and 2) given an integrity level of "normal". Integrity levels are also part of the token.
What it means is that *even when you log on as an administrator* you do not possess any administrative or god-like rights. You are a standard user.
When you invoke a program that has a manifest which states that it requires some form of administrative rights, Windows will prompt you for "elevated" privileges. Only when you accept to use your administrative privileges will the process be started with a token with higher than standard user rights.
It really is a much more elegant solution than the stupid effective user in Linux, where the description of a process rights is strongly tied to a user: There must exist a user with the specific sets of rights you want the process to have. Not so on Windows: Any process can have it's own token with fewer or more rights/privileges.
You can turn off UAC (don't!), which is why Microsoft must write the disclaimer *If the current user is logged on with administrative user rights*. If you turn off UAC and log in with an administrative account - then you run all processes with full permissions/privileges.
When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage?
They did fix it. You are just ignorant.
How many of these problems could be mitigated if this were not MicroSoft's default approach?
The answer is 92% - and it is mitigated by default.
Type
[Start] e n v
Win 10 responds with
"Edit environment variables for your account"
Type
[Enter]
Still works