Slashdot Mirror
Windows RT Jailbroken To Run Third-Party Desktop Apps
An anonymous reader writes "We all knew it was just a matter of time, now it looks like Windows RT has been Jailbroken. From the article: 'The hack, performed by Clokr, exploits a vulnerability in the Windows kernel that has existed for a long time — since before Microsoft ported Windows from x86 to ARM, in fact. Basically, the Windows kernel on your computer is configured to only execute files that meet a certain level of authentication. There are four levels: Unsigned (0), Authenticode (4), Microsoft (8), and Windows (12). On your x86 Windows system, the default setting is Unsigned — you can run anything you like. With Windows RT, the default, hard-coded setting is Microsoft (8); i.e. only apps signed by Microsoft, or parts of Windows itself, can be executed.'"
Microsoft locked Windows RT down because it wanted to slowly get rid of the Win32 cruft dating back to the 80s and 90s. That cruft does exist now and is used to run things like Office and Notepad etc. but Microsoft can easily rewrite them in the future. What will happen to Putty, VNC and the like then? They will break,and then again we will blame Microsoft for it. That's the reason to lock it down.
This space for rent.
All 3 of them.
This may border on being pedantic, but I'd call this a crack instead of a jailbreak. It sounds like they're just patching a kernel value ... not breaking out of a jailshell.
I expect MS will probably just find a way to patch it up in the near future.
Theoretically you could run some kind of shell on there, so yes, you could run android or linux, but it'd still be running within windows.
And yes, you'd need to flip this bit each time you booted.
What is more interesting is the fact you maybe able to completely rewrite the whole thing; getting rid of windows entirely...
- http://www.milkme.co.uk
This trend of making it hard/impossible to run what you want on your computing devices is just despicable. I predict that not many years from now there won't be a commonly-used platform where you can download whatever you want and run it. We may be way past the year 1984, but we sure seem headed for 1984.
Imagine!
"Need" implies there are people using it, which is a conclusion we might want to take off our mat for the time being.
I foresee an update to Windows RT tomorrow (or soon thereafter) to plug this serious threat to user security (have to secure users from getting apps somewhere else that Redmond doesn't make money from)
The fine article has a big link in the first paragraph: "What is WIndows RT?"
Oh, wait...
No sig today...
Am I missing something here? How can anyone develop new applications for Windows RT and test run them?
"Windows RT Gains Solution to Allow Customers to Run Any Software They Choose"
And we wonder why people don't "get" Software Freedom. Somebody please remember to name the next software-freedom work-around "murder" just to keep the bad PR going.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Still have to be complied to ARM right?
Interesting post. I'm no security buff, but whitelisting doesn't sound like it's inheriently a bad thing, and I don't think anyone would argue so, but if that's the route you go, the default should have to be that the user themselves is gatekeeper, with the option of enabling it such that they can use another party to manage their walled garden for themselves.
:P
Really, building your own walled garden of executables from places you trust actually sounds like a pretty clever idea. It also sounds like Linux repositories with a filemask of 110. Or maybe using a host file instead of DNS.
Support the EFF and Creative Commons. The war is coming, and they're supporting you...
I wonder idly if this could be used to run Wubi to install Ubuntu in that strange dual-boot-from-a-boot-file-that-sits-within-Windows way that it does. If so, that'd be a pretty big breakthrough.
Come to think of it, I have no idea how Wubi would react to a "secure boot" set up.
Except the problem with your whole premise is that you forget the user.
Basically Apple "whitelists" what Apps can run under iOS (and are clearly moving that way for OSX too), yet people rail against it and even go so far as to remove the "whitelist" (e.g. jailbreak).
The problem comes down to who does the vetting and testing of an application to add it to a whitelist? If it is the user, they've proven they can't be trusted because they'll "vet" any new screensaver/antivirus/cursor application that comes along. If it is a central organization (Microsoft/Apple/Google/etc..) you then run into conflicts of interest in what they think you should do with the platform and what you actually need/want to do (e.g. what happens when you have a problem that can't be solved by any existing approved application?).
There is no simple single solution to the problem of security. A real solution by nature needs to be multilayered which means there is some complexity and ultimately users have to take responsibility for their actions. The idea that a single company/program can keep you safe just keeps perpetuating this idea that you don't have to pay attention to what your are downloading/executing and it's that mentality that allows malware to continue to be so successful.
When someone says, "Any fool can see
That should be including Android, since Android is Linux. It is both the Linux kernel, and the typical user space tools you would find in a base GNU/Linux distribution. You can adb shell into a device and ls, cp, etc. and you can even get Busybox from the Google Play store. If you have the skills, nothing stops you from cross-compiling your own FOSS software and installing it as well. On many (almost all?) devices, you can also build and install a custom kernel, as has been done time and again.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I'm glad to see that you are finally up to speed AC. Now if you could just learn how to create an account!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
From my understanding of Secure boot, I don't think wubi would work because I think it modifies the part of the bootloader that is signed. It is also probably only designed for x86 systems and as Windows RT runs on ARM, it might not be compatible. (It at least partially acts like a boot loader which is quite architecture specific)
null
Once you can attach a remote debugger to a process you can pretty much run whatever code you want, it's just not user-friendly. The big thing here is that a system process is bypassing sanity checks on API calls (for speed, I assume) and so it's exploited to run arbitrary code in kernel mode, and then you have the whole system (in this case, it just flips the switch to allow any app to run, for the current session only I assume, it won't persist to the next boot).
MS may restrict the processes to which the debugger can attach to fix this, so you can't attach to any system process which uses the faster API calls lacking sanity checks. Assuming there's no way to get other programs to use those versions of DLLs, this would close the exploit, unless the user removes the hotfix (can you do that in RT?) or reinstalls Windows (if that's easy to do).
Either way a tool to package up the remote debugger side of things into something usable would be fairly trivial to make, just gotta capture the network activity of the exploit and then automate it so normal users just push a button and then trigger the proper breakpoint by adjusting the system volume.
See subject-line, & that quote of myself, vs your misinterpretation of what I wrote (or perhaps you just missed it)...
You mean the subject line that is simply showing as "Whitelisting of a sort (& the future of securi"?
As far as possibly misinterpreting you, I will admit your writing style is not as clear as it could be but you clearly go on about whitelisting being most/all of the security solution (to the extent you talk about it possibly replacing AV software). If that was not the point you were trying to get across, then I apologize but that is how it came across to me.
See above again - in corporate environs, where THE MACHINE IS NOT THE USERS but the companies? That'd be the network admins doing the testing (hopefully).
In this case the network admins/company are still the end user even if the result is that they represent more than one physical person. Using the iOS example without buying into Apple's development system there is no "authorized" method for the company to build an internal application and deploy it to their employees iOS devices. So in that case the corporate environment operators still have limited control to do their own vetting. Even still, I've been on the receiving end of "by god you will install this" in the corporate environment so you still have the "users can't be trusted" element there as well.
Whitelisting is the security holy grail, but as with all hardline security measures it forgets that there needs to be a balance between letting the user perform the work that needs to be done while still protecting them from themselves.
I spent some time in a secure environment that tightly controlled what ran on desktops and needed an application that was allowed, but not for the role I was filling. We spent 6 months going back and forth before finally getting approval and getting it installed. Because what I was doing couldn't wait those 6 months we had to work around the restrictions in the meantime. While I am sure of my personal computers, that I had to use them and email the data back and forth opened a vector for a potential problem (as well as violating the corporate rules so you can be sure I had it in writing from a couple levels of management that they approved of what I was doing).
The flip side of course is that I've also worked in environments where everyone had admin rights and could install anything the wanted (though the written policy said they "can only use approved software"). That environment was a constant headache for security and the help desk due to the near constant malware issues (which almost always manifested as performance problems).
Those are the reasons that a rigid whitelisting policy can't work in the real world. Exceptions have to be able to be made in a responsive manner, but that control still needs to be somewhat centralized. In a corporate environment this is relatively easy to do (in principle anyway), but when you start talking about home users that becomes near impossible as there is no way a large company (Apple/Google/MS/...) know what all their users need to do (and really have no business knowing that level of detail in my opinion) and the individual can't really be trusted either. Really the only way to possibly do it would be a community based system, but even there you need some kind of control to keep the likes of 4chan from polluting it by tagging malware as "safe" and Photoshop as "unsafe".
With the exception of Bionic, which is smaller and weaker than glibc. Android's compatibility with standard GNU-based Linux platforms is extremely weak.
The entire Android software ecosystem is built with "standard" Linux (typically Ubuntu, but I've used a few others to do it), and has the Linux kernel at its core. While the build system has repo, that is a wrapper around gitFurthermore, it has the Linux kernel and ABI it is therefore fairly straightforward to build the software you find in a "typical" Linux distribution and install it, so long as one has the skills. This is the old naming argument again, which I'm not about to get into. The fact remains that Android is Linux, as we both agree.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Due in no small part to the fact that there is no such thing as a standard GNU/Linux distribution. If you had experience developing for Embedded Linux systems you would realize how unfounded your "complaint" is. We have been using Busybox and non-glibc libc for over a decade.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
No, due to the fact that they eschew GNU entirely, which is actually pretty common across Linux distributions with the sole exception of Android.
I'm aware that Embedded Linux don't use glibc, they tend to use uClibc or (worse) something proprietary.
But Android is still deliberately separated from GNU/Linux platforms because Google wanted to control it all and cater to handset vendors that don't like having to comply with the GPL.
I think this article linked through TFA reviewing the WOA appstore sums it up nicely "But for now, x86 compatibility isn't just a check box: It's a doorway back to a land of sanity.". Kinda sad they are actually charging more than iPad for Surface when its quite obvious just from reading the reviews their appstore is completely broken and worthless.
BTW it may be a little petty of me, but since i called it months ago that the WOA and Win 8 appstore would be a trainwreck, since they couldn't make GFWL functional after years and a competitor that would be easy enough to copy they sure as hell wouldn't be able to pull off an appstore for a different arch so I'd like to say "I told you so" to those that doubted me and do the dance of smug superiority.
ACs don't waste your time replying, your posts are never seen by me.
> What is more interesting is the fact you maybe able to
> completely rewrite the whole thing; getting rid of windows
> entirely...
That's what I meant.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Ummmm.... no. You can sideload "Metro" applications just fine (after running one command to unlock this capability). The packages must be signed, but they can be signed by anybody (including self-signed), so long as they chain to any trusted certificate. Visual Studio generates an install script for the package that checks whether its (also auto-generated) signing cert is trusted, and if not, offers to install the cert for you. You can also do so manually (just double-click the cert file and follow the usual import steps).
So, .APPX (Metro application bundle) files don't require "Microsoft" signing level. What about the binaries they contain, though? It turns out that those don't need to be signed at all. At least a month back, a different branch of the "run everything on Windows RT" project bore fruit; we could run "desktop" apps within the AppContainer of a "Metro" app. (WinRT isn't supposed to include the APIs to launch new processes directly, but you have to be linked against the system call interface on Windows anyhow, which means it's possible to just scan the address space for the NtCreateProcess entry point and call it.) These apps don't have to be signed *at all* even without anything like the hack posted here. They run with low Integrity Level and have (by default) extremely limited permissions (access the System32 directory, their install directory, and their data directory, and only the last of those with write permissions), but they do not have to be signed.
There's no place I could be, since I've found Serenity...
You need to research Linux and its license. It is impossible to use Android without having to comply with the GPL. Every Android manufacturer is bound by the GPL.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
My research tells me that manufacturers of Android devices are bound by the GPL only in kernel space. The user space tends toward the Apache license.
You do realize that sideloading "Modern" (a.k.a. "Metro") applications is fully possible and officially supported, right?
Microsoft states that it "can detect fraudulent use of a developer license on a registered machine." What information is sent back to Microsoft when a developer license is used to allow Microsoft to "detect fraudulent use"?
You can sideload "Metro" applications just fine (after running one command to unlock this capability).
How hard is it to script the periodic commands to renew this capability?
Since when attaching the debugger constitutes a jailbreak?
Since the operating system allowed the user to attach a debugger without a recurring payment. This, as I understand it, is one difference between the Windows RT developer license model and the $99 per year model used by Xbox Live Indie Games, iOS, and Windows Phone 7.
Ms only hardware??? then they will need to make alot more choices then what apple has and lunix will get all the high end systems / good video cards.
Ms may even try to lock in video cards as well.
Android isn't the only Linux distro that isn't GNU. You are correct in that.
Now, what part of that fact makes the GP complaint unfounded? Android could be a GNU/Linux distro, Google decided that it wouldn't, and this makes Android worse.
Rethinking email
You are both making the assumption that Android has to use Bionic. That is what makes the complaint unfounded.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
This would be good if they keep their independence from Microsoft and allow these phones to do some good.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Whitelisting will need NO Centership other then apps the crash the system.
and more then 1 app store as well a 100% free zone for both dev's and users.
The important point here, other than that yes, you can sideload and debug on RT without paying extra for the privilege, is that the value which must be changed is in kernel mode, but RT only allows user-mode debugging. The kernel debugger is disabled via Secure Boot (the bootloader understands the debug switch, but if you attempt to set it, Secure Boot will block you).
Typically, attaching a debugger to a user-mode process still doesn't let you modify kernel memory; the debugged process and the debugger itself are both running in ring 3, which means they can't write to ring0-only memory (the kernel's address space). The hack here is that there's a security bug in Windows where a trusted system process can make a call into the kernel which, due to lax parameter checking, can be used to overwrite a part of kernel memory. While the kernel *does* verify that it is this trusted process calling the vulnerable function, the kernel does not check that the process hasn't been modified by a debugger. Attaching a debugger to a system process requires Admin, but Windows RT allows running processes as Admin so that is not a problem.
There's no place I could be, since I've found Serenity...
Accessibility by definition grants extra ability to those who have less or no skill.
There's nothing wrong with accessibility in general. But it incurs a cost. By granting the unskilled extra power that they have no skill in weilding, accessibility makes the landscape that much more dangerous. There are those who are willing and able to become skilled, and through an increase in accessibility, there will be an increase in these people. But this happens at the cost of having to deal with everybody else, who are not interested in such things and willingly accept the collateral damage.
It's like guns (which I mention because it is a popular topic being debated), or vehicles (which I mention because this is Slashdot, and a car analogy is necessary). Accessibility to guns or cars makes the landscape that much more dangerous for the very same reason. For cars, it's getting into accidents. For guns, it's hitting an innocent bystander (or oneself). Accidents are fairly frequent. Bystanders getting shot happens less so, but occasionally when police start firing into a crowded area (individuals are not bystanders when they are the target).
One can argue that in the hands of a skilled operator, a gun would be that much more dangerous for everyone. There certainly is merit to this argument. But that particular argument comes with a presumption of a self-destructive actor, which in all cases would be equally devastating (within context). The same self-destructive actor in a car analogy would drive a car just to ram other people's cars off a cliff road, or a semi just to T-bone a full schoolbus. There are such actors, these events are impossible to stop irrespective of overall population skill (though one can argue that a skilled operator has a small chance of preventing such actions). A better, more effective method of prevention would be to attack the self-destructive impulse itself, and operating skill does not factor into this at all.
I don't support strictly regulating computer usage the way that cars are (albeit loosely) regulated. But I do understand where companies are having trouble finding that middle ground, the spot where they can offer a powerful product to everybody such that anyone with skill can make full use of it, but where they can also limit the unskilled to very specific abilities. Companies are at both the mercy of the consumer who can choose to use a competing product, and of the 3rd party vendor who can choose to develop for a competing product.
Android, I think, comes very close to this, but there are still numerous destructive (within context) things unskilled individuals can inadvertantly do with an Android device. For starters, surrendering habits and other personal information to Google or other companies, and allowing and encouraging this behavior, constitutes dangerous behavior, though possessing a cell phone effectively amounts to having a 24/7 tracking device so the point is moot for many pieces of information.
Windows, stemming from the computing paradigm of yore, did not control the users actions at all, which resulted in the mess that is Windows. Developers and users alike made a mess of the ecosystem. Meanwhile iOS and Windows RT is a bit too controlling, resulting in developers' annoyance for the former and full abandonment for the latter. There are other problems with Windows RT (and Windows 8) from the user interface side. but that I leave for a separate discussion.
(As for gun control, there are certain measures which I support, in particular, focusing the control on bullets and taking the mental health (history) of a gun buyer into account, but there are other measures I oppose on the grounds of being ineffective, draconian, or both. But that is neither here nor there.)
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Did you fail to read what the OP wrote? Or is it that you are intentionally trying to change the subject?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I agree that it is illegal to distribute Android without agreeing to the GPL. The difference between Android and GNU/Linux lies in how much code is affected by the GPL. Unlike GNU/Linux, Android limits the extent of GPL covered code to the kernel, so any changes to user space need not be distributed to the public as source code.
Android caters to manufacturers that don't like GPL compliance by minimizing the amount of what they have to do that they don't like. Say a manufacturer has two relevant options: either A. do what it doesn't like to a small extent, or B. do what it doesn't like to a large extent. The manufacturer is more likely to tolerate doing A as what it considers the lesser of two evils. In this case, Android is A and a GNU stack is B. With Android, they have to distribute source code only for changes to the kernel. With GNU/Linux, they would have had to distribute source code for all modifications, including the launcher modifications that manufacturers use to distinguish their products from those of other manufacturers.
Honestly, I have a hard time knowing for sure. I couldn't have downmodded you, as posting prohibits moderation. This is, of course, ruling out sockpuppet accounts or any sort of malarkey like that, but you'll have to take me on my word it wasn't me.
:)
To speculate on your question, I would suggest that it's probably something to do with the fact that you have a bit of a reputation for what I might call an erratic posting style. You're usually very long winded on a topic, and I've seen you post things that are strange tangents that don't really apply to the topic of the thread. Then again, I'm not sure if those are actually you, or perhaps impersonators mimicking your very unique style of writing.
All of these things somewhat make you stand out in a crowd, which makes you a target for anyone who needs one, deserving or otherwise. Tell you what: Try toning down the posting style to something more subtle for a couple posts. Maybe don't sign them apk. Maybe go with Alexander (I believe that is your name) or some other moniker. See if people react the same way. Call it a social experiment.
Support the EFF and Creative Commons. The war is coming, and they're supporting you...