You download a program that appears legit (and may be mostly legit, or be a hacked version of a legit program), and are running it.
But why would I do that?
Ok, try this: You browse the Internet using Firefox. Lots of vulnerabilities discovered each month, 4 remote code executions already in 2015. An attacker has infected an add or a legitimate or fringe site you visit. Attack code executes and the attacker now runs his code in your Firefox. The malicious code hooks into X. The code can intercept the lock screen, but it can *also* monitor each and every keystroke entered into ANY other window - including terminal windows - without you noticing it. Lock the screen and unlock it and your password is compromised. Run a sudo in a terminal window and you are pwned!
Scoth: "Windows has had the ctrl-alt-del to log in/unlock since literally the first version of Windows NT, 3.1, in 1993. "
You: "In 1993, Windows didn't have an NT kernel."
AC: "In 1993, Windows NT 3.1 was released. Not to say that the non-NT product line ended at the same time." (AC factually correct here: Windows NT 3.1 was released in July 1993)
operaghost: "Windows NT 3.1 didn't have an NT kernel? Color me confused. No, scratch that-- color you wrong."
You: "Go to a typical computer store in 1993, ask for Windows, and they wouldn't give you an NT kernel." (now you try to deflect; why bring in the "typical computer store"? the issue was *Windows NT*)
So, your claim was that Windows NT didn't have an NT kernel. The TFA was about Windows NT, and Windows NT certainly HAD the NT kernel, it certainly HAD the "attention sequence" Ctrl-Alt-Del, and it certainly WAS released and available.
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device.
Except in Windows. Since Vista user interface privilege isolation prevents unauthorized processes from grabbing keyboard/mouse events or sending messages to windows owned by another process, even if that process is running as the same user. To be allowed to grab keyboard/mouse, the process must have declared that intent in the manifest *and* it must have been launched from an installed location (program files or windows system). Furthermore, such hooking/messaging is also masked out at the intrinsic level by UAC - specifically by integrity levels. A lower integrity process is simply not allowed - manifest or not - to send messages or install keyboard/mouse hooks at a higher integrity level process.
X is especially bad in this regard, as it does not even protect against shatter attacks and eavesdropping on windows from *another users* processes. If you elevate to root - e.g. sudo from a terminal window - any other process can *still* eavesdrop on keyboard events.
Some alternatives sound nice but fail horrificly when the come in contact with people, especially the ones that let any people within a group grant access to others with zero oversight.
An access control system where everyone (with access?) can grant access to others sounds bad. However, I don't think that's the only alternative to me-us-everyone rwx. In fact, I don't know that such a system that exists at all. You usually needs to be the owner of a resource (or in the "owners" group) to grant privileges in a DAC system. Some systems also allows owners to grant specific rights on the security attributes to non-owners - i.e. the right to grant access.
Within a short period of time with such a "everyone can grant or deny access" scheme you end up with almost everything wide open
How about a system where only owners or designated security administrators can grant/deny access? The issue here was that a developer *wanted* access to a file from a non-owner and non-group member account. Lacking finer grained ACLs, that leaves only "everyone".
It sounds like you believe that discretionary access control (DAC) is the alternative to Unix filesystem permissions. It's not. Unix filesystem permissions is itself a DAC system, albeit a very limited one. DAC only means that the owner of a resource (or a designated security administrator of a resource) can grant access to others. Because the creator of a file is often considered the owner, creators can often grant access to whom they choose.
However, if a user has been granted "read" access to a resource he can usually not grant it to someone else, unless he is the owner. Do you know of a system where, by default, you can grant the same permissions that you have been granted?
This kind of exploit, a local privilege escalation exploit, used to be very significant, but is significant in a declining number of cases, as old-style Unix multiuser systems are a smaller and smaller proportion of systems.
An attacker who has exploited a Firefox vulnerability (there are still many found and patched each month) is running as a *local user* on your machine. Trying to explain these types of vulnerabilities away is disingenuous, if not downright complacent.
Unix/Linuxs permission system is 70-era bit-saving stupid. There is no other way to put it.
While this is clearly a mistake by someone packaging the distro, they were certainly not helped by a system where you cannot adequately express permissions. ACLs are available, but they are still kludges and they fell like a bolt-on with many tools still not recognizing them.
When a developer meets the limit of what can be expressed with a single-group me-us-everybody, he will often look for the path of least resistance. Unfortunately that is often relaxing permissions along the coarse-grained me-us-everyone, often ending up with everyone as in this case.
Incremental is the worst system for restoring. Needing the last full and *all* backups since the last full. Differential is better in that you need the last full and *one* differential. What I think you really mean is versioned backups (not over-written). You can restore from Tuesday's backup (whether full, differential, or incremental is irrelevant), and Tuesday's won't be wiped when Wednesday's is written.
Windows Image backup does *reverse* incremental: An image of the disk is stored as a vhd (virtual hard drive) along with reverse increments so that previous versions can be created. You can attach the vhd and use the "previous versions" feature to go back in time.
And what checks that signature? Code running from ROM perhaps?
In UEFI secure boot firmware can only be updated by a *signed* package. A thunderbolt attack would only be able to *request* a change to firmware, but it would have been rejected had Apple implemented secure boot.
With the open sourcing of.NET, I wonder how far they've gone. Is it the exact same runtime used on Windows, now fully open sourced like the JVM?
Yes
Was the entire.NET platform open sourced, or just a subset?
The entire *server* stack - i.e. everything you need to run a.NET server application. They have even created a small-footprint webserver Kestrel for Linux based on libuv. The reason for libuv actually touches on a very important aspect/advantage of modern.NET (and to some extent, Windows Server) . More on that below.
Doesn't.NET require IIS to run web apps?
No. You have *always* been able to just self-host the ASP.NET bits. However, MS have taken it a step further and completely separated out the bits of the pipeline so that you can pick and choose. For a long time there have been plugins for Apache httpd and others that would allow you to run Mono. Those will work fine regardless of whether ASP.NET is provided by Mono or MS. Kremel mentioned above, but you can use any other way. ASP.NET vNext is "pluggable".
In the Java world, the entire platform and runtimes are open source.
In the.NET world, the entire platform and runtimes are open source, and the platform specification is governed by international standards organizations (ECMA and ISO).
Microsoft grants patent licenses for anyone who wants to create implementations of the specifications, and Microsoft *specifically* does not require paid testing suites and they do NOT assert that using the APIs constitutes copyright infringement.
And now for some reflections on the differences: Microsofts stack - especially with the latest.NET and Windows Runtime - have grown to become completely focused on asynchronous programming. Windows (the NT line) with the "overlapped IO" available from the initial version always had a very high-performing "completion" oriented async model for all types of IO. While this model could yield much better scalability, to leverage it you had to program in a "callback" style that were often at odds on how you think about a problem (sequentially) as well as poor match for constructs such as exception handling, looping/branching etc.
With C# 5.0 (and the equivalent VB.NET) async became an integrated feature of the language. This is not about smart synchronization primitives, multithreading or similar "low level" concepts. This is aboy having a language that effortlessly allows a programmer to express a sequential problem in a way that allow asynchronous processing all the way down to the system level where overlapped IO will be used. Without invading the way the solution is expressed.
This is huge. I am aware of only one other ecosystem that does something similar: node.js. Python has the capability, but there's no ecosystem built around it where the capability is the default way to design libraries and APIs.
In terms of enabling and supporting async programming style, C#,.NET (and F#) is the most mature option out there, along with the "new" kid node.js.
Java only recently acquired the ability to process web requests asynchronously (yielding the thread to process other requests) - but the language and APIs make it exceedingly hard to leverage this capability for anything useful. If you look up articles for how to do async in Java you will notice a strange t
Expect this certificate to be revoked in near future. This will close that avenue, and cause all machines infected drivers signed by the cert to refuse to load the malware driver.
And cause all machines with legitimate Sony drivers (if there is such a thing?) signed with the same cert to refuse to load those too.
Unfortunately, yes. Sony will have to re-issue those legitimate drivers and sign them with a new cert. That is actually a good reason why a code signing certificate for widely distributed software absolutely should reside within a HSM, which will make the private key impossible to steal.
What benefit does the attacker get by signing the malware with a company's certificate?
Windows has a mechanism where kernel-mode drivers must be signed. For certain mandatory, early-load drivers (e.g. anti-malware tools, measured boot tools) the drivers must be signed by Microsoft. But Windows allows other kernel-mode drivers to be loaded as long as they are signed using a valid, non-revoked code-signing cert from (IIRC) Verisign.
Kernel-mode drivers can obviously access memory in kernel-mode. This is a common way for malware to take foothold on a Windows machine. It is really hard to ensure that Malware is executed during boot otherwise.
Expect this certificate to be revoked in near future. This will close that avenue, and cause all machines infected drivers signed by the cert to refuse to load the malware driver.
In practice, a certificate is nothing more than a long password that's impossible for a normal human to memorize. So it ends up in a file somewhere, if not several "somewheres", where it can be easily stolen.
If certificates are used correctly they are stored in some kind of certificate store where they cannot just be "stolen".
In the Windows certificate store, when you import a certificate, the default is to set the key to "non exportable". Non exportable means that you'll never get the key from that store - at least not from your user context (given that it is stored encrypted but on the local disk, an "root" user with access to physical disk sectors could theoretically reconstruct the key - but not without running with severely elevated privileges).
You can still use the certificate to sign with - but you'll need to go through the crypto api which asks the certificate store to perform the signing without giving the private key away. This works even if the key is held in a connected hardware secure module (HSM) which will add more guarantee that private keys *never* leave the device.
For better security you *should* use the cert store to generate the non-exportable private key to begin with. It can still be signed by an external entity like Verisign - even without the private key ever leaving the secured store.
There is no excuse for having the private key stolen. The private key of a certificate used to sign software/drivers from a corporation like Sony should *definitively* have been created by a HSM and there should be guarantee that the key never leaves that HSM. There are well known products which will still allow you to load-balance HSMs, synchronize and take backups where the key will only ever leave the box in an encrypted container that will only be understood by a box that have been paired with the originating HSM/cert store.
Shell shock is not malware, it's a bug in Bash that can possibly be exploited if you have exposed Bash to the outside world through some poorly implemented service.
So many ppl come here and post that Windows is not only safe, but that it is targeted because of numbers. Yet, it is obvious that NSA and GCHQ targeted Windows. Why? I doubt that it was numbers, but ease of cracking.
If your targets use Windows it would be a real stroke of genius to distribute attacks against Linux, don't you think?
Duh.
So, in the meantime, how many companies will start switching to *nix?
What is the *nix equivalent to secure boot? Signed kernel modules? What is the *nix equivalent to Measured Boot and Network Access Protection? How does an organization automatically and immediately detect and isolate potentially infected hosts?
Every operating system out there will experience exploitable vulnerabilities. Applications running on top of the operating systems will experience exploitable vulnerabilities. The most recent severe vulnerabilities that have been mass exploited are *nix vulnerabilities like Heartbleed and Shellshock. No operating system is immune.
That's why defense in depth is important. Windows starts it's defenses before boot, by using Secure Boot. This ensures that only approved bootloaders run. It prevents bootkits. Some Linux distros support a weak form of secure boot (it doesn't protect all types of resources, notably scripts and config files are not digitally signed). Windows loads all kernel components from signed "cabinet" files - protecting all assets used during boot. If a rootkit tampers with any of the files, the system will refuse to boot.
During boot, before loading *any* kernel module, Windows will compute a hash of the module and record it in the TPM hardware module along with name, size, dates and other metadata. Upon successful boot (but before other hosts will accept traffic from the system) the OS asks the TPM for a signed "health" record. The TPM will issue a signed document with all the recorded info that the host can present to a health certificate server. The health cert server can investigate the list of loaded modules and compare against known whitelists and/or blacklists. If everything checks out, the health cert server issues a certificate the booting host must use when communicating with other hosts. Unless it can present such cert, the other hosts will refuse to communicate with the host.
Does 'Nix support such security in depth?
Such targeted attacks will target whatever operating system is being used by the target. Targets must consider the possibility that any host can be breached through an application or OS vulnerability. With that recognition, they must ensure expedient diagnosis and isolation. In that area, a Windows server infrastructure can be set up to become extremely strong.
"New security updates released for the WordPress.. fix cross-site scripting (XSS) vulnerabilities that could allow attackers to take control of websites."
Embedded javascript in a comment box could trigger exploits on Microsoft Internet Explorer running on Microsoft Windows desktops.
All of the current Windows versions are derived from Windows NT. The security model was developed for Windows NT. It is the very same extensible (through SIDs) model that has later been extended for AD and later for UAC (mandatory Integrity Control) in Windows Vista.
It's the world's biggest target for malware, it's a monoculture, and it has a security model that tends toward convenience over security
Yes - the "dragnet" attacks tends to go after the most victims. If your attack has a certain chance of succeeding (like a social engineering attack), you'd be stupid to go after the 1% instead of the 90%. Now, in a *targeted* attack where the attacker singled out a specific victim or group of victims - the attacker will go after whatever those targets use.
and was actually bolted on after-the-fact.
Nope. The current strain of Windows was created from scratch with the present security model from the get-go. The security model is based on tokens and it was designed to be extensible from the start. Also from the start, the designers envisioned that a process or even a thread could have a token *different* from the user token - i.e. a process could run with permissions/privileges different from the user.
The Windows security model also goes beyond the naive file system-focused model where only file system-like objects were seen as important to secure. In Windows - from the start - all system objects (files, directories, windows, processes, threads, shared memory regions, mutexes, users, groups etc) are accessed through object-oriented handles. When you open a handle you specify the access you request, where each object type has it's own access types. The security check is performed right there when opening the object - instead of on each syscall. If the access you request is granted, a system object is created with a jump table (think virtual method table) where the functions you requested access are mapped to the actual system functions, and the other functions mapped to "denied". The upshot of this is that even though Windows has a much more advanced security model which could make security checks more involved, it will usually perform better because it does *not* have to check security permissions on each syscall.
Contrast that with Unix/Linux where the security model initially only considered file system objects. There were only 2 levels: regular users and root, and a large number of functions could only be performed by root. When it was realized that other system types might also need security descriptors, the existing file system was "adapted" by "mapping" non-file system objects to become file system-like. Talk about bolted on!
The Unix/Linux security model is also the only one with a deliberate drilled hole: The SUID/setuid. Here you have a too limited model where regular users are unable to perform perfectly reasonable functions, like changing their own passwords. So what do you do? You let them run as the only user that *can* perform the function, and pray that the process somehow prevents them from performing any of the other functions root can do while running they are running as root. This is a blatant violation of the least privilege principle, but it is now deeply engraved in all Unix systems. Needless to say that this is the most common path for pwning Unix/Linux systems, going all the way back.
The Unix/Linux model was so bad that NSA had to create SELinux (talk about bolted-on!) which creates it's own competing security "context" (a token). When you want to audit the security of a Unix/Linux system you have to consider 3 competing models: 1) The "original" file-system oriented discretionary model with the SUID hole, 2) the sudoers and 3) SELinux/apparmor or whatever has been bolted on the top.
Especially 1) and 2) are worrying, because it is neigh impossible to audit those sufficiently as long as just a single SUID/sudo command is allowed: How do you (as an auditor) know *what* the SUID/sudo command can actually do? Did *you* install the executable, did *you* monitor the compilation from source? What *other* things can ps or even ping do that you don't know about? If I hold up a file or point to a process on your system as
Excuse my ignorance but is there such a thing as plain ascii conf files in the Microsoft world? Or will the proprietary binary registry be ported/required too for the.NET libs to access app/system settings? How will it adhere 100% to the *nix security conventions? TIA.
.NET does not rely on the registry, except for some of the COM that will not be ported. In.NET the config files are XML files, e.g. a program called MyStuff.exe will have a config file called MyStuff.exe.config - which must contain XML configuration according to the (extensible) schema. Pretty sweet, actually, if only they would modernize it a bit. I'm hearing that they are doing exactly that - making the config system even more "pluggable".
Config files for server applications can "inherit" base config files: First, the base config file is applied and then the more specific config file. The specific config file can remove, replace, change or add items from configured collections/items, unless explicitly forbidden by the base file.
I'm not the GP and I'm a self-proclaimed C# fan, but: The Java collections seems to have been more well thought out from the beginning with abstract types (interfaces) for different types of collections, such as bag, list, set, stack, queue, vector etc and then concrete implementations with separate characteristics, such as hashed, sorted etc..NET is catching up, especialy in the 4.x versions, but Java (IIRC) still has proper priority queues that has no equivalent in.NET.
If you see comparisons between.net and java, it's usually that the past 10 years.net has evolved and java sometimes catches up a tiny bit.
Agreed.
I always thought that java collections were weaker since in.net even an array is also still a collection, they have collections for just about anything you need, and with LINQ you've got an incredibly powerful way of manipulating/creating/accessing collections.
I always found the Java collections a bit stronger conceptually. For instance, it really bothered me that there was no hashed set (there is now), and I had to play tricks with HashTable by using the same value for key and value to mimic a set. It was particularly annoying as I went from C++ to Java to C#. Java seemed to have lifted the collections from STL where they seemed to have been very well designed. C# collections always stroke me as having been "thrown in there". Thankfully they have improved a lot since then.
and with LINQ you've got an incredibly powerful way of manipulating/creating/accessing collections.
LINQ cannot be overestimated. Large parts of code is actually manipulating collections, and LINQ is just awesome. Also the fact that C#/.NET generic collections were always properly reified, unlike Javas fake generics (type erasure) which causes all kinds of strange corner cases and problems. C# generic collections allow primitive types to be used for type parameters, and always without performance loss due to runtime downcasting like in Java.
This is Denmark, yes? You know, the country that is surrounded by oceans that have some of the strongest tides? I think Denmark could produce almost all of it's power though tidal power plants. The only real trick is how to buffer the power during the lull of high and low tide.
You are mostly correct solar (fotovoltaic) is a dumb idea, but there are more renewable power sources than solar and wind.
There is no tide to speak of in Denmark. I'm not sure that we'd classify the sea between the islands (Denmark is basically an island nation) as "oceans". The tides are usually 1m or less, most pronounced in the eastern part facing the North Sea, much less pronounced in the western parts that sits in the Baltic Sea.
But the flat topology and the fact that most of Denmark is islands, there's a *lot* of coastline, and wind is a much preferred as renewable energy source here. I don't think people realize how much it is blowing here. Damned wind!
It is correct that generating most energy from wind runs the risk that prolonged periods with high pressure (which means little wind and clear skies == frezzing cold during winter) can not generate enough wind to meet the demand.
Another problem is that in large parts of Denmark (e.g. the entire Copenhagen metropolitan area) most households get their heating from centralized "surpluss" heat from electricity production - burning coal at the moment.
It is commendable not to waste heat,and as you can probably imagine, Denmark has a huge investment in this centralized heat distribution system.
But I'd like to know, where will we get the heating from once electricity is produced from wind and solar?
The OpenGL API is fundamentally opposed to an efficient implementation. It allows developers to do fundamentally inefficient things (like dramatically changing configurations at the last second, before rendering, requiring the driver to recompile/reoptimise shaders and/or reverify states) immediately before rendering. Furthermore, it doesn't allow developers to do fundamentally efficient things (i.e. giving the driver a heads up about exactly what state/shader combinations it's going to use, so that they can be made ready at compile/launch time).
Good points. But while the API may not coerce you into writing performant code like (perhaps) the alternatives, it does not make it impossible or practically unobtainable. I will readily admit that I know very little about 3D programming, shaders and the like.
However, modern games are all built upon some form of game engine that in turn is typically used in multiple games. Few game developers write to the API anyway, so if the few (relative to number of games they support) game engines were optimized, wouldn't this difference go away?
Which brings us back to the developers of the game engines: If the developers of the game engines would invest the effort to create engines with high performance on Linux, multiple games would benefit from it immediately. OTOH, if the game engine developers *do not* optimize their code for Linux, there is very, very little actual game developers can do about it, short of creating their own game engine. Which is a monumental task.
So microsoft's relationship with the govt is relavent here but google's is not?
Yeah, the NSA hacked Google to get at their data, Microsoft was a willing collaborator.
Since you so dishonestly quoted text from an article without linking back to it, here is the link: http://www.theguardian.com/wor...
This concerns the "Prism" program - which since the initial bruhaha has been revealed to be little more than an automated way to comply with (presumably) lawful requests from law enforcement agencies. (Note: I strongly disagree with the constitutionality of having a secret court issuing secret orders; it totally undermines the democracy)
The participation in the automated system (aka Prism) does not require a company to comply with more FISA requests, nor does non-participation allow a company to *not* comply with FISA requests. It simply has no bearing on it.
Importantly, the automated system does NOT(!) allow the agencies more access to users' data. Each FISA request will STILL have to be considered on a case-by-case basis, and lawyers for the company will STILL have to review all material sent to the agency through PRISM before hitting the "send" button.
And conspicuously absent from your quote is the fact that while Microsoft was mentioned in the title, Skype, Apple, Google, Facebook and Yahoo were also mentioned.
Little information is available on the actual design of PRISM, and basically all of the speculation was based on this single slide from the Snowden leak: https://en.wikipedia.org/wiki/...
From that slide you can see that Microsoft was indeed the first company to comply with FISA orders through PRISM, but that Yahoo, Google, Facebook, Paltalk(?), YouTube, Skype, AOL and Apple all followed.
So you are grossly misrepresenting facts, being dishonest and out lying about the information in a transparent attempt to taint Microsoft while letting Google of the hook. Now, why would you do that? Anonymous cowardly liar.
Slashdot Mirror
But why would I do that?
Ok, try this: You browse the Internet using Firefox. Lots of vulnerabilities discovered each month, 4 remote code executions already in 2015. An attacker has infected an add or a legitimate or fringe site you visit. Attack code executes and the attacker now runs his code in your Firefox. The malicious code hooks into X. The code can intercept the lock screen, but it can *also* monitor each and every keystroke entered into ANY other window - including terminal windows - without you noticing it. Lock the screen and unlock it and your password is compromised. Run a sudo in a terminal window and you are pwned!
How's that?
Yes, that is exactly my point.
Nice try. But no, you are BSing.
Scoth: "Windows has had the ctrl-alt-del to log in/unlock since literally the first version of Windows NT, 3.1, in 1993. "
You: "In 1993, Windows didn't have an NT kernel."
AC: "In 1993, Windows NT 3.1 was released. Not to say that the non-NT product line ended at the same time."
(AC factually correct here: Windows NT 3.1 was released in July 1993)
operaghost: "Windows NT 3.1 didn't have an NT kernel? Color me confused. No, scratch that-- color you wrong."
You: "Go to a typical computer store in 1993, ask for Windows, and they wouldn't give you an NT kernel."
(now you try to deflect; why bring in the "typical computer store"? the issue was *Windows NT*)
So, your claim was that Windows NT didn't have an NT kernel. The TFA was about Windows NT, and Windows NT certainly HAD the NT kernel, it certainly HAD the "attention sequence" Ctrl-Alt-Del, and it certainly WAS released and available.
And you are dishonest.
I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?
Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device.
Except in Windows. Since Vista user interface privilege isolation prevents unauthorized processes from grabbing keyboard/mouse events or sending messages to windows owned by another process, even if that process is running as the same user. To be allowed to grab keyboard/mouse, the process must have declared that intent in the manifest *and* it must have been launched from an installed location (program files or windows system). Furthermore, such hooking/messaging is also masked out at the intrinsic level by UAC - specifically by integrity levels. A lower integrity process is simply not allowed - manifest or not - to send messages or install keyboard/mouse hooks at a higher integrity level process.
X is especially bad in this regard, as it does not even protect against shatter attacks and eavesdropping on windows from *another users* processes. If you elevate to root - e.g. sudo from a terminal window - any other process can *still* eavesdrop on keyboard events.
Some alternatives sound nice but fail horrificly when the come in contact with people, especially the ones that let any people within a group grant access to others with zero oversight.
An access control system where everyone (with access?) can grant access to others sounds bad. However, I don't think that's the only alternative to me-us-everyone rwx. In fact, I don't know that such a system that exists at all. You usually needs to be the owner of a resource (or in the "owners" group) to grant privileges in a DAC system. Some systems also allows owners to grant specific rights on the security attributes to non-owners - i.e. the right to grant access.
Within a short period of time with such a "everyone can grant or deny access" scheme you end up with almost everything wide open
How about a system where only owners or designated security administrators can grant/deny access? The issue here was that a developer *wanted* access to a file from a non-owner and non-group member account. Lacking finer grained ACLs, that leaves only "everyone".
It sounds like you believe that discretionary access control (DAC) is the alternative to Unix filesystem permissions. It's not. Unix filesystem permissions is itself a DAC system, albeit a very limited one. DAC only means that the owner of a resource (or a designated security administrator of a resource) can grant access to others. Because the creator of a file is often considered the owner, creators can often grant access to whom they choose.
However, if a user has been granted "read" access to a resource he can usually not grant it to someone else, unless he is the owner. Do you know of a system where, by default, you can grant the same permissions that you have been granted?
This kind of exploit, a local privilege escalation exploit, used to be very significant, but is significant in a declining number of cases, as old-style Unix multiuser systems are a smaller and smaller proportion of systems.
An attacker who has exploited a Firefox vulnerability (there are still many found and patched each month) is running as a *local user* on your machine. Trying to explain these types of vulnerabilities away is disingenuous, if not downright complacent.
Unix/Linuxs permission system is 70-era bit-saving stupid. There is no other way to put it.
While this is clearly a mistake by someone packaging the distro, they were certainly not helped by a system where you cannot adequately express permissions. ACLs are available, but they are still kludges and they fell like a bolt-on with many tools still not recognizing them.
When a developer meets the limit of what can be expressed with a single-group me-us-everybody, he will often look for the path of least resistance. Unfortunately that is often relaxing permissions along the coarse-grained me-us-everyone, often ending up with everyone as in this case.
Incremental is the worst system for restoring. Needing the last full and *all* backups since the last full. Differential is better in that you need the last full and *one* differential. What I think you really mean is versioned backups (not over-written). You can restore from Tuesday's backup (whether full, differential, or incremental is irrelevant), and Tuesday's won't be wiped when Wednesday's is written.
Windows Image backup does *reverse* incremental: An image of the disk is stored as a vhd (virtual hard drive) along with reverse increments so that previous versions can be created. You can attach the vhd and use the "previous versions" feature to go back in time.
And what checks that signature? Code running from ROM perhaps?
In UEFI secure boot firmware can only be updated by a *signed* package. A thunderbolt attack would only be able to *request* a change to firmware, but it would have been rejected had Apple implemented secure boot.
With the open sourcing of .NET, I wonder how far they've gone. Is it the exact same runtime used on Windows, now fully open sourced like the JVM?
Yes
Was the entire .NET platform open sourced, or just a subset?
The entire *server* stack - i.e. everything you need to run a .NET server application. They have even created a small-footprint webserver Kestrel for Linux based on libuv. The reason for libuv actually touches on a very important aspect/advantage of modern .NET (and to some extent, Windows Server) . More on that below.
Doesn't .NET require IIS to run web apps?
No. You have *always* been able to just self-host the ASP.NET bits. However, MS have taken it a step further and completely separated out the bits of the pipeline so that you can pick and choose. For a long time there have been plugins for Apache httpd and others that would allow you to run Mono. Those will work fine regardless of whether ASP.NET is provided by Mono or MS. Kremel mentioned above, but you can use any other way. ASP.NET vNext is "pluggable".
How will you run a .NET web app on Linux?
curl -sSL https://raw.githubusercontent.... | sh && source ~/.kre/kvm/kvm.sh
In the Java world, the entire platform and runtimes are open source.
In the .NET world, the entire platform and runtimes are open source, and the platform specification is governed by international standards organizations (ECMA and ISO).
Microsoft grants patent licenses for anyone who wants to create implementations of the specifications, and Microsoft *specifically* does not require paid testing suites and they do NOT assert that using the APIs constitutes copyright infringement.
And now for some reflections on the differences: Microsofts stack - especially with the latest .NET and Windows Runtime - have grown to become completely focused on asynchronous programming. Windows (the NT line) with the "overlapped IO" available from the initial version always had a very high-performing "completion" oriented async model for all types of IO. While this model could yield much better scalability, to leverage it you had to program in a "callback" style that were often at odds on how you think about a problem (sequentially) as well as poor match for constructs such as exception handling, looping/branching etc.
With C# 5.0 (and the equivalent VB.NET) async became an integrated feature of the language. This is not about smart synchronization primitives, multithreading or similar "low level" concepts. This is aboy having a language that effortlessly allows a programmer to express a sequential problem in a way that allow asynchronous processing all the way down to the system level where overlapped IO will be used. Without invading the way the solution is expressed.
This is huge. I am aware of only one other ecosystem that does something similar: node.js. Python has the capability, but there's no ecosystem built around it where the capability is the default way to design libraries and APIs.
In terms of enabling and supporting async programming style, C#, .NET (and F#) is the most mature option out there, along with the "new" kid node.js.
Java only recently acquired the ability to process web requests asynchronously (yielding the thread to process other requests) - but the language and APIs make it exceedingly hard to leverage this capability for anything useful. If you look up articles for how to do async in Java you will notice a strange t
Expect this certificate to be revoked in near future. This will close that avenue, and cause all machines infected drivers signed by the cert to refuse to load the malware driver.
And cause all machines with legitimate Sony drivers (if there is such a thing?) signed with the same cert to refuse to load those too.
Unfortunately, yes. Sony will have to re-issue those legitimate drivers and sign them with a new cert. That is actually a good reason why a code signing certificate for widely distributed software absolutely should reside within a HSM, which will make the private key impossible to steal.
What benefit does the attacker get by signing the malware with a company's certificate?
Windows has a mechanism where kernel-mode drivers must be signed. For certain mandatory, early-load drivers (e.g. anti-malware tools, measured boot tools) the drivers must be signed by Microsoft. But Windows allows other kernel-mode drivers to be loaded as long as they are signed using a valid, non-revoked code-signing cert from (IIRC) Verisign.
Kernel-mode drivers can obviously access memory in kernel-mode. This is a common way for malware to take foothold on a Windows machine. It is really hard to ensure that Malware is executed during boot otherwise.
Expect this certificate to be revoked in near future. This will close that avenue, and cause all machines infected drivers signed by the cert to refuse to load the malware driver.
In practice, a certificate is nothing more than a long password that's impossible for a normal human to memorize. So it ends up in a file somewhere, if not several "somewheres", where it can be easily stolen.
If certificates are used correctly they are stored in some kind of certificate store where they cannot just be "stolen".
In the Windows certificate store, when you import a certificate, the default is to set the key to "non exportable". Non exportable means that you'll never get the key from that store - at least not from your user context (given that it is stored encrypted but on the local disk, an "root" user with access to physical disk sectors could theoretically reconstruct the key - but not without running with severely elevated privileges).
You can still use the certificate to sign with - but you'll need to go through the crypto api which asks the certificate store to perform the signing without giving the private key away. This works even if the key is held in a connected hardware secure module (HSM) which will add more guarantee that private keys *never* leave the device.
For better security you *should* use the cert store to generate the non-exportable private key to begin with. It can still be signed by an external entity like Verisign - even without the private key ever leaving the secured store.
There is no excuse for having the private key stolen. The private key of a certificate used to sign software/drivers from a corporation like Sony should *definitively* have been created by a HSM and there should be guarantee that the key never leaves that HSM. There are well known products which will still allow you to load-balance HSMs, synchronize and take backups where the key will only ever leave the box in an encrypted container that will only be understood by a box that have been paired with the originating HSM/cert store.
Shell shock is not malware, it's a bug in Bash that can possibly be exploited if you have exposed Bash to the outside world through some poorly implemented service.
Yeah. Like Apache.
So many ppl come here and post that Windows is not only safe, but that it is targeted because of numbers. Yet, it is obvious that NSA and GCHQ targeted Windows. Why? I doubt that it was numbers, but ease of cracking.
If your targets use Windows it would be a real stroke of genius to distribute attacks against Linux, don't you think?
Duh.
So, in the meantime, how many companies will start switching to *nix?
What is the *nix equivalent to secure boot? Signed kernel modules? What is the *nix equivalent to Measured Boot and Network Access Protection? How does an organization automatically and immediately detect and isolate potentially infected hosts?
Every operating system out there will experience exploitable vulnerabilities. Applications running on top of the operating systems will experience exploitable vulnerabilities. The most recent severe vulnerabilities that have been mass exploited are *nix vulnerabilities like Heartbleed and Shellshock. No operating system is immune.
That's why defense in depth is important. Windows starts it's defenses before boot, by using Secure Boot. This ensures that only approved bootloaders run. It prevents bootkits. Some Linux distros support a weak form of secure boot (it doesn't protect all types of resources, notably scripts and config files are not digitally signed). Windows loads all kernel components from signed "cabinet" files - protecting all assets used during boot. If a rootkit tampers with any of the files, the system will refuse to boot.
During boot, before loading *any* kernel module, Windows will compute a hash of the module and record it in the TPM hardware module along with name, size, dates and other metadata. Upon successful boot (but before other hosts will accept traffic from the system) the OS asks the TPM for a signed "health" record. The TPM will issue a signed document with all the recorded info that the host can present to a health certificate server. The health cert server can investigate the list of loaded modules and compare against known whitelists and/or blacklists. If everything checks out, the health cert server issues a certificate the booting host must use when communicating with other hosts. Unless it can present such cert, the other hosts will refuse to communicate with the host.
Does 'Nix support such security in depth?
Such targeted attacks will target whatever operating system is being used by the target. Targets must consider the possibility that any host can be breached through an application or OS vulnerability. With that recognition, they must ensure expedient diagnosis and isolation. In that area, a Windows server infrastructure can be set up to become extremely strong.
"New security updates released for the WordPress .. fix cross-site scripting (XSS) vulnerabilities that could allow attackers to take control of websites ."
Embedded javascript in a comment box could trigger exploits on Microsoft Internet Explorer running on Microsoft Windows desktops.
Source? Or just trolling?
This 'highly advanced' computer worm will only work on Microsoft Windows:
It is not a worm. It is a trojan, i.e. the user has to invite the trojan (the "dropper") inside for it to work.
A worm is an automated infection which propagates automatically from system to system. Like the Shellshock worms, Code Red, Nimda.
Any particular reason you chose to call it a worm, despite that it was described as a trojan in the summary as well as in TFA?
Current strain of Microsoft Windows? Which ones?
All of the current Windows versions are derived from Windows NT. The security model was developed for Windows NT. It is the very same extensible (through SIDs) model that has later been extended for AD and later for UAC (mandatory Integrity Control) in Windows Vista.
It's the world's biggest target for malware, it's a monoculture, and it has a security model that tends toward convenience over security
Yes - the "dragnet" attacks tends to go after the most victims. If your attack has a certain chance of succeeding (like a social engineering attack), you'd be stupid to go after the 1% instead of the 90%. Now, in a *targeted* attack where the attacker singled out a specific victim or group of victims - the attacker will go after whatever those targets use.
and was actually bolted on after-the-fact.
Nope. The current strain of Windows was created from scratch with the present security model from the get-go. The security model is based on tokens and it was designed to be extensible from the start. Also from the start, the designers envisioned that a process or even a thread could have a token *different* from the user token - i.e. a process could run with permissions/privileges different from the user.
The Windows security model also goes beyond the naive file system-focused model where only file system-like objects were seen as important to secure. In Windows - from the start - all system objects (files, directories, windows, processes, threads, shared memory regions, mutexes, users, groups etc) are accessed through object-oriented handles. When you open a handle you specify the access you request, where each object type has it's own access types. The security check is performed right there when opening the object - instead of on each syscall. If the access you request is granted, a system object is created with a jump table (think virtual method table) where the functions you requested access are mapped to the actual system functions, and the other functions mapped to "denied". The upshot of this is that even though Windows has a much more advanced security model which could make security checks more involved, it will usually perform better because it does *not* have to check security permissions on each syscall.
Contrast that with Unix/Linux where the security model initially only considered file system objects. There were only 2 levels: regular users and root, and a large number of functions could only be performed by root. When it was realized that other system types might also need security descriptors, the existing file system was "adapted" by "mapping" non-file system objects to become file system-like. Talk about bolted on!
The Unix/Linux security model is also the only one with a deliberate drilled hole: The SUID/setuid. Here you have a too limited model where regular users are unable to perform perfectly reasonable functions, like changing their own passwords. So what do you do? You let them run as the only user that *can* perform the function, and pray that the process somehow prevents them from performing any of the other functions root can do while running they are running as root. This is a blatant violation of the least privilege principle, but it is now deeply engraved in all Unix systems. Needless to say that this is the most common path for pwning Unix/Linux systems, going all the way back.
The Unix/Linux model was so bad that NSA had to create SELinux (talk about bolted-on!) which creates it's own competing security "context" (a token). When you want to audit the security of a Unix/Linux system you have to consider 3 competing models: 1) The "original" file-system oriented discretionary model with the SUID hole, 2) the sudoers and 3) SELinux/apparmor or whatever has been bolted on the top.
Especially 1) and 2) are worrying, because it is neigh impossible to audit those sufficiently as long as just a single SUID/sudo command is allowed: How do you (as an auditor) know *what* the SUID/sudo command can actually do? Did *you* install the executable, did *you* monitor the compilation from source? What *other* things can ps or even ping do that you don't know about? If I hold up a file or point to a process on your system as
I know this is is meant as a jokey comment, but it's worth noting that VS2015 has native Git support as well so Github etc. works without any plugins.
VS 2013 (including Community) has Git support out of the box and works just fine with GitHub as well.
Ahem. It works. Sorta. It's slow, mildly confusing and it totally screws up if you use subrepositories. Looking forward to VS2015.
disclaimer: I'm on the VB/C# language team.
Question: PowerShell is implemented using .NET. Will we see PowerShell on Linux?
Excuse my ignorance but is there such a thing as plain ascii conf files in the Microsoft world? Or will the proprietary binary registry be ported/required too for the .NET libs to access app/system settings? How will it adhere 100% to the *nix security conventions? TIA.
.NET does not rely on the registry, except for some of the COM that will not be ported. In .NET the config files are XML files, e.g. a program called MyStuff.exe will have a config file called MyStuff.exe.config - which must contain XML configuration according to the (extensible) schema. Pretty sweet, actually, if only they would modernize it a bit. I'm hearing that they are doing exactly that - making the config system even more "pluggable".
Config files for server applications can "inherit" base config files: First, the base config file is applied and then the more specific config file. The specific config file can remove, replace, change or add items from configured collections/items, unless explicitly forbidden by the base file.
Can you explain?
I'm not the GP and I'm a self-proclaimed C# fan, but: The Java collections seems to have been more well thought out from the beginning with abstract types (interfaces) for different types of collections, such as bag, list, set, stack, queue, vector etc and then concrete implementations with separate characteristics, such as hashed, sorted etc. .NET is catching up, especialy in the 4.x versions, but Java (IIRC) still has proper priority queues that has no equivalent in .NET.
If you see comparisons between .net and java, it's usually that the past 10 years .net has evolved and java sometimes catches up a tiny bit.
Agreed.
I always thought that java collections were weaker since in .net even an array is also still a collection, they have collections for just about anything you need, and with LINQ you've got an incredibly powerful way of manipulating/creating/accessing collections.
I always found the Java collections a bit stronger conceptually. For instance, it really bothered me that there was no hashed set (there is now), and I had to play tricks with HashTable by using the same value for key and value to mimic a set. It was particularly annoying as I went from C++ to Java to C#. Java seemed to have lifted the collections from STL where they seemed to have been very well designed. C# collections always stroke me as having been "thrown in there". Thankfully they have improved a lot since then.
and with LINQ you've got an incredibly powerful way of manipulating/creating/accessing collections.
LINQ cannot be overestimated. Large parts of code is actually manipulating collections, and LINQ is just awesome. Also the fact that C#/.NET generic collections were always properly reified, unlike Javas fake generics (type erasure) which causes all kinds of strange corner cases and problems. C# generic collections allow primitive types to be used for type parameters, and always without performance loss due to runtime downcasting like in Java.
I don't think they are legally bound to keep that promise
They are: Promissory estoppel. It is like a one-sided contract - i.e. one that you do not have to sign for it to be legally binding for Microsoft.
This is Denmark, yes? You know, the country that is surrounded by oceans that have some of the strongest tides? I think Denmark could produce almost all of it's power though tidal power plants. The only real trick is how to buffer the power during the lull of high and low tide.
You are mostly correct solar (fotovoltaic) is a dumb idea, but there are more renewable power sources than solar and wind.
There is no tide to speak of in Denmark. I'm not sure that we'd classify the sea between the islands (Denmark is basically an island nation) as "oceans". The tides are usually 1m or less, most pronounced in the eastern part facing the North Sea, much less pronounced in the western parts that sits in the Baltic Sea.
But the flat topology and the fact that most of Denmark is islands, there's a *lot* of coastline, and wind is a much preferred as renewable energy source here. I don't think people realize how much it is blowing here. Damned wind!
It is correct that generating most energy from wind runs the risk that prolonged periods with high pressure (which means little wind and clear skies == frezzing cold during winter) can not generate enough wind to meet the demand.
Another problem is that in large parts of Denmark (e.g. the entire Copenhagen metropolitan area) most households get their heating from centralized "surpluss" heat from electricity production - burning coal at the moment.
It is commendable not to waste heat,and as you can probably imagine, Denmark has a huge investment in this centralized heat distribution system.
But I'd like to know, where will we get the heating from once electricity is produced from wind and solar?
The OpenGL API is fundamentally opposed to an efficient implementation. It allows developers to do fundamentally inefficient things (like dramatically changing configurations at the last second, before rendering, requiring the driver to recompile/reoptimise shaders and/or reverify states) immediately before rendering. Furthermore, it doesn't allow developers to do fundamentally efficient things (i.e. giving the driver a heads up about exactly what state/shader combinations it's going to use, so that they can be made ready at compile/launch time).
Good points. But while the API may not coerce you into writing performant code like (perhaps) the alternatives, it does not make it impossible or practically unobtainable. I will readily admit that I know very little about 3D programming, shaders and the like.
However, modern games are all built upon some form of game engine that in turn is typically used in multiple games. Few game developers write to the API anyway, so if the few (relative to number of games they support) game engines were optimized, wouldn't this difference go away?
Which brings us back to the developers of the game engines: If the developers of the game engines would invest the effort to create engines with high performance on Linux, multiple games would benefit from it immediately. OTOH, if the game engine developers *do not* optimize their code for Linux, there is very, very little actual game developers can do about it, short of creating their own game engine. Which is a monumental task.
So microsoft's relationship with the govt is relavent here but google's is not?
Yeah, the NSA hacked Google to get at their data, Microsoft was a willing collaborator.
Since you so dishonestly quoted text from an article without linking back to it, here is the link: http://www.theguardian.com/wor...
This concerns the "Prism" program - which since the initial bruhaha has been revealed to be little more than an automated way to comply with (presumably) lawful requests from law enforcement agencies. (Note: I strongly disagree with the constitutionality of having a secret court issuing secret orders; it totally undermines the democracy)
The participation in the automated system (aka Prism) does not require a company to comply with more FISA requests, nor does non-participation allow a company to *not* comply with FISA requests. It simply has no bearing on it.
Importantly, the automated system does NOT(!) allow the agencies more access to users' data. Each FISA request will STILL have to be considered on a
case-by-case basis, and lawyers for the company will STILL have to review all material sent to the agency through PRISM before hitting the "send" button.
And conspicuously absent from your quote is the fact that while Microsoft was mentioned in the title, Skype, Apple, Google, Facebook and Yahoo were also mentioned.
Little information is available on the actual design of PRISM, and basically all of the speculation was based on this single slide from the Snowden leak: https://en.wikipedia.org/wiki/...
From that slide you can see that Microsoft was indeed the first company to comply with FISA orders through PRISM, but that Yahoo, Google, Facebook, Paltalk(?), YouTube, Skype, AOL and Apple all followed.
So you are grossly misrepresenting facts, being dishonest and out lying about the information in a transparent attempt to taint Microsoft while letting Google of the hook. Now, why would you do that? Anonymous cowardly liar.