SteadyState virtualizes the OS directories transparently on the disk. File writes/updates are directed to a secluded area. You can set it to simply delete those journaled updates upon restart/signoff. Any malware will be effectively gone. Windows Update would still be possible when signing in as the SteadyState administrator (creating an updated image), but that's kind of moot at this point.
Is that why Windows and IIS got hacked all the time while Linux and Apache/PHP very rarely ?
Citation needed.
Because it had better security ?
Yes, Windows servers are compromised less because it is far easier to set those up securely. Especially IIS+ASP.NET is way more secure than Apache+PHP in almost any way; not least the programming model where PHP almost encourages SQL injections and XSS where with.NET/MVC it is hard to create SQL injections and XSS vulnerabilities.
There was a project for Linux kernel that gives advanced ACL capabilities to Linux systems. I forgot the name of it now, but basically.. whatever was possible to do, you could do it.
ACLs are available with most distros nowadays. However, the point is they are bolted on. They represent a MAC model which competes with simplistic linux file system permissions. You do not switch to ACLs, you turn them on and have to manage them in parallel with regular file system permissions. Thus they complicate the security model rather than refine it (and they still support inheritance pretty poorly). Now throw in SELinux, SUID root utilities and *nobody* stand any realistic chance of performing a reliable security assesment of a Linux system.
There are hundreds of projects that you can add and use.. (stable, tested projects).
The problem with security is an admin that thinks blocking port 22 is gonna keep him safe... if he uses Linux, and the other problem with security in general... is using Windows. The other problem with security is management hiring idiots (above mentioned jolly bunch, block port 22 and all ok) and/or outsourcing administration to cheap indian companies that work for peanuts.
Coming from someone who cannot remember the "project" with (and obviously does not use) ACLs. Nice.
The best locks in world, which Linux does come with, do not help if the door is left unlocked. Microsoft OTOH has no doors.
The biggest threat to linux in the last five years has not been the architecture of linux
The biggest threat to Linux security is the number smug, amateurish Linux admins who believe they are all safe because their tribal platform is blessed with magic fairy dust that makes vulnerabilities un-possible.
On the architectural level, the biggest threat to Linux is the outdated security model inherited from the 1970 where saving a few bytes at the expense of better layered security was all the rage. This is exemplified by: * The woefully outdated permission model where proper ACLs had to be bolted on, and to this day competes with and confuses security planning and auditing (Windows NT had ACLs from the start). * The fact that only the file system objects were considered for access control. (In Windows the security model extends to all objects: Threads, processes, synchronization objects (locks, semaphores), sockets/ports etc) * Security tokens do not exist. Instead of granular tokens you have to use "effective users" - breaking the Least Privilege Pinciple (Windows NT was designed with granular process tokens from the start).
When creating a new IIS in Windows, the site is automatically set up with the most restrictive isolation. You do not even have to create a user for the site to run under - the security model already knows about identities and each site gets it own identity which must be explicitly granted permissions to read the file system.
but the willingness of programmers, in particular weak programmers from the WIndows world coming over and applying the same philiosophies to linux development.
That's rich. The absolutely most security-ignorant ecosystem is the LAMP community. PHP with it's abysmal security record is the worst language *ever*.
One project might use "customer" another "client" or "businessname". Each of these may have a "description", "overview", "synopsis" and a "type"/"kind"/"businesstype" field.
So code discovery of data doesn't work unless we have agreed to standardized field names in advance
Why doesn't it work? Have a look at $metadata. You get schemas for your data. OData has full discovery. The only "standardized field name" you need to know in advance is $metadata.
... but now there's always exceptions to look out for and name conflicts.
Now even if we know the names of every field, how do we know exactly what sort of data will be returned? A name alone is nothing unless we can ensure its type, and remove all assumptions about what it can contain.
OData was originally designed for XML. JSON was added later. With XML you can (and should) use namespaces to disambiguate field names between different entities/domains.
W3C was something a committee did which was academic. Only Netscape and MS specific CSS and HTML mattered and websites needed to include specific workarounds for one or the other etc. Man, people forget how dark the web was 10 years ago.
This. And everyone seems to have forgotten how Netscape pushed the awful JSSSas an alternative to CSS. Microsoft actually pushed CSS at the time.
At the time, the best browser actually won. It was the neglect by MS in the years following that was/became the big problem, one for which MS has rightfully earned a lot of scorn. MS never wanted the web to evolve too fast as it could undermine the very lucrative desktop business.
But at the time of Netscape/MS rivaly, it was actually Netscape who tried to foist abominations like JSSS and the "layer" tag upon us.
You're an idiot as standard users still have access to threads, processes, and the file system. This means you can attach a rogue process or malware to an admin one which happens to run as a service. It can then be executed with full admin privileges.
Nope. A standard user (which even includes admins who have not elevated through UAC prompt yet) can only attach to processes running under *the same* account as itself, and then only to a process/thread within the same *session* as itself.
In Windows, all services are launched in a separate session from the shell - meaning that direct attachment is not possible from a user shell to a service - even if they are running as the same user.
Unlike *nix'es, Windows uses proper tokens. What a process is permitted to do is not limited by a user account - rather each process has its own fine-grained token. By default a process inherits the token from the process that spawned it - but it can be further limited. When you log in, the shell process is created with a token which has all administrator privileges stripped from it and which runs with medium integrity level. So even if you are an administrator you will still get a standard user token. Upon login another token was also created - one which has high integrity level and has not been stripped of administrative privileges you may hold.
When you launch a process where the manifest demands elevated rights, Windows will issue the UAC prompt. If you accept then you get to run the process with your "super" token. This prompt is running with "high" integrity level (and by default even on a separate desktop) to prevent malicious processes already running as you from "remote controlling" the prompt at click the ok button for you.
It is important to note that unlike on Unix where you elevate to "root" with sudo - and thus receive privileges far beyond what is called for - Windows UAC prompt *can not* grant you privileges you did not already hold (well - if *another* user authenticates at the prompt you can "borrow" that users privileges).
It is worth noting that while all browsers were successfully attacked, the "Unicorn" class challenge Windows 8.1 x64/IE11/EMET was *not* exploited - even though it would have netted the attacker a cool $150,000.
It is broken by design because sudo protects the utility used to access the protected resource rather than protecting the resource itself.
Relying on and allowing such a mechanism does two things to your security model:
1) It forces users with otherwise legitimate access to go through specific utilities (actually fire up processes) just to access a they should have access to in the first place.
2) Worse, it takes away your ability to assess who has access to the resource. Since there are multiple SUID root utilities on the system, and multiple sudo utilities with sudoers config, you really have to know the capabilities of each of those utilities to know that they cannot be used by an unauthorized user to access the protected resource.
Had you used a system where the resource was protected and where there were no sudo/SUID bypass mechanism available, you can generate a report of users with access to the resource simply by querying the user/group permissions. As an added benefit, anyone with legitimate access could then access the resource and not be forced fire up a process and to go through a specific utility to access the resource.
Not only is the sudoers 144-page-incomprehensible, the whole idea is broken to begin with:
First, you design a simplistic security model where a single user/group (root) is hardwired to a number of privileges not available to anyone else and where standard users' privileges are inherently too limited.
Then you start drilling *holes* (big holes) because the model clearly does not meet real world requirements. SUID lets users run as root for the duration of the process. A single escape during the processing will allow the otherwise non-privileged user to drop up to a root shell. A single memory corruption may allow the user to run unrestricted as root. And there has been *many* such exploits in all variants of Unix, including Linux, OS X etc.
Because the operating system security model did not allow fine grained access control to resources, someone came up with the idea to protect the *utility* instead of the resource or system function (and took out a patent, no less) . WTF? Why does the OS not protect the syscall to change system time or change password? Why did they design a system where you would need to start a frigging SUID root process to do that?
It is a direct violation of the least privilege principle, one of the core security principles. Every time you let someone invoke sudo you let them run as root and just hope that the utility does not contain vulnerabilities, because the *consequence* of a vulnerability is total system compromise.
sudo is a design flaw in the ActiveX class. In fact, they are really very much alike: In both cases you hand over the keys to the house and cross your fingers that the visitor is well behaved while he is in there.
Once the holes have been drilled, sudo (and SUID roots) make it extremely hard for security auditors to assess whether the security has been set up with meaningful barriers: They can not audit a resource and determine who has access to view or change it. The sudo / SUID model always leave the possibility that some utility allows another access to the resource. I.e. the auditor cannot assess a single resource, rather he must assess the system in its entirety. And when doing that he must also trust that the SUID root utilities and sudo utilities are what they pretend to be, i.e. he must validate the utilities as well; or accept the possibility that one or more of the utilities is actually capable of more than it advertises.
Had the designers opted for a proper model where resources (processes, syscalls, devices, ports) were actually protected by access control lists, the auditor could have audited the security settings and remain confident that there was not some *other* way to access the resource.
The SUID root / sudo idea was a terrible one. It was necessitated because of an woefully inadequate security model. Rather than fixing the model (like e.g. create real tokens with claims) the designers decided to drill holes. Many holes.
Good for individual commands, but not for learning the syntax. That's the bit that stumps me.
man syntax
system responds with 2 topics: about_Command_Syntax and about_Path_Syntax
man command_syntax
system responds with help "about the command syntax".
and the fact that some syntaxes work on some commands and not on others annoys me.
What are you talking about? PowerShell commands are extremely consistent - not like the different syntax conventions used for ls, find, xargs and dd - just to name a few examples of Nix inconsistencies. PowerShell commands always follow the pattern Verb-Noun. A limited set of verbs are strongly encouraged (to the point where a command author has to bend over to break the convention) and their conventional uses are explained in command author guidelines. While PowerShell commands may take positional parameters they *always* have a name (the position is optional to allow for a short form). Parameter names are *always* specified using dash (like -ParameterName). Parameter names can be shortened as long as they are still unambigious. This is all a feature of the *shell* - parameter parsing is not left to each command, i.e. a command is forced to use the consistent scheme.
I would like a good but brief overview of how powershell commands are actually structured without having to go through a massive Microsoft Press book
From running man command_syntax:
TOPIC about_Command_Syntax
SHORT DESCRIPTION Describes the syntax diagrams that are used in Windows PowerShell.
LONG DESCRIPTION The Get-Help and Get-Command cmdlets display syntax diagrams to help you construct commands correctly. This topic explains how to interpret the syntax diagrams.
Syntax Diagrams Each paragraph in a command syntax diagram represents a valid form of the command.
To construct a command, follow the syntax diagram from left to right. Select from among the optional parameters and provide values for the placeholders.
Windows PowerShell uses the following notation for syntax diagrams.....
The problem isn't GUI users, its the fact Powershell is complete shite.
All this time I cant get a basic instruction on how Powershell works without getting a 500 page book. Learning Linux and AIX wasn't this hard (granted the Linux training covered a lot of the AIX ground).
Try typing man. That should get you started.:-)
You can start by knowing only 4 commands. Everything is discoverable through those: * Get-Help (aliases help, man): Get help for a command or for a topic, e.g. "man ls" gets help for the "ls" command (ls being alias for get-childitem). Try typing man about - that'll give you a list of "about" topics that explain PowerShell quite nicely. * Get-Command (alias gcm): Lists available commands. * Get-Member (alias gm): Lists available members on items output from a command, e.g. ls|gm will tell you that ls produces DirectoryInfo and FileInfo objects each with an extensive set of properties such as name, path, length, access time etc. * Get-Alias (alias "alias"): Lists defined aliases. Several aliases help Nix users get started, e.g. "ls", "ps".
Does that matter? With code pages marked as read-only and data pages marked as no execute is it even possible to turn such a buffer overflow into an exploit other than DoS any more?
Yes it is. The technique is referred to as "return oriented programming". That is why you need strong ASLR to make DEP/NX effective. Windows and OS X (IIRC) are the only OSes with strong and complete ASLR.
Huh, and I suppose you wrote the Powershell out in the longer way just by coincidence? While that longhand version might be better in a script for documentation purposes, it's way more verbose than is needed for a quick cmd-line run.
While it is generally true that using the longer versions of cmdlet names and parameter names and using named parameters instead of positional ones increases readability in scripts, this specific "longer version" is just stupid. It has been artificially made longer and more complicated and has actually *lost* readability bc of that process. One can only guess to the intentions behind that "example". It is certainly very, very bad PowerShell.
In fact, (...googling...) it looks like there are network-adapter cmdlets in server 2012 and win 8.1 so it may just be a matter of upgrading PS.
Yes. In fact, the functions from the NetAdapter module has been automatically created as wrappers from WMI objects.
Which is shorter? Which is more readable? Which is more robust against changes (like new properties/columns)? Which is more consistent across related commands? Which is more discoverable? Which is more extensible?
Note how the PowerShell version does *not* need to engage in string parsing, and how it does *not* need to rely on specific file content formats. The advantages of objects in the pipeline.
Btw, if you want PowerShell to output in the same metadata-stripped format as from bash/ifconfig, you can make the PowerShell command even shorter, without sacrificing readability: PowerShell: (Get-NetAdapter).macaddress
Powershell was designed to market Windows server, providing something that looks familiar to Unix/Linux admins. It's by no means a replacement for VBScript. (Which is *not* the same thing as VBA.) VBScript, being COM-centric, is uniquely suited to accomplishing all sorts of tasks on Windows. It just happens to be getting "deprecated" as part of Microsoft's overall strategy: They want to attract people to Windows server while converting "civilian" Windows into virtually a kiosk OS.
Sorry, BS. PowerShell is a foundation technology in Windows, unlike VBScript. Since Windows 7, the troubleshooting packs are actually written in PowerShell! The troubleshooting utilities are automatically launched by the system when e.g. network problems occur.
PowerShell is every bit as COM capable as VBScript. PS uses a "unified" type system where multiple object models (COM,.NET, WMI etc) are surfaced as common PS objects.
VBScript is definitively legacy (and deprecated). I will actually wager a bet that there is not a single meaningful VBScript that could not be written shorter and more elegant with PowerShell.
It is object oriented so the data transfer between processes is more robust. Also all the commands' manual pages come with extensive documentation and lots of great examples. UNIX man pages usually lack examples.
Most bashers (no pun intended) miss several aspects of PowerShell simply because they view it as just another shell.
One such aspect is the fact that PowerShell is designed to operate directly with an application's core logic (the object model) whether that application was designed using COM or.NET. Virtually *all* of Window's features and even 3rd party applications for Windows are designed using one of those models. So the barrier to exposing the functionality to the CLI (PowerShell) is really, really low, and even older applications that predates PowerShell or that were never designed for PowerShell (like iTunes) lend themselves to CLI manipulation. Forget about needing to craft a suite of external CLI tools - your app is inherently exposed to command line manipulation.
Another often overlooked aspect is how PowerShell is designed to run in-process within an application. The CLI is just *one* possible host for PowerShell. Alas, you can add the PowerShell engine to your app and immediately leverage existing commands to manipulate the in-process memory objects of your application. So not only is it *easy* to expose your application to automation, you can actually take advantage of the PowerShell engine to save work for your own in-application automation. With workflow engine integration in PowerShell 3.0 (it is now at 4.0) this is a great way to orchestrate workflows activities in an easy-to-manage way.
app-based network transparency is a feature of RDP. It hasn't been implemented in Windows as far as I know of but I'm optimistic that Wayland's proposed reliance on RDP for network applications will implement it per-app rather than full desktop.
It has been available for several years now. It is used in App-V to access applications running on a server but displaying it'a GUI in windows on the local machine. I don't think you can use app-based RDP in a client Windows to client Windows configuration, though.
I sincerely apologize for the harsh tone. That was uncalled for, and I shot off without reading what I wrote and how it comes across. Again, I apologize.
Like you I have some "triggers". One of my triggers is blanket dismissal. I think what I perceived as your blanket dismissal was what triggered. You are correct about Ruby-on-Rails. It turned out that it was not up to the job. But at the same time it *did* popularize the "web-MVC" pattern in a way that Java frameworks (e.g. Struts) never achieved.
When someone praises a new technology as the new "best thing since sliced bread", we should approach it with a healthy portion of skepticism. However, we must also keep our minds open to new advances.
Reactive Programming is not an alternative to OO or FP. It complements both, and at the same time it promises to make certain aspects much more manageable, like e.g. asynchronous and parallel processing.
As for Pwn2Own, the results really are meaningless - if you break OS X, you win a MacBook. If you break Windows, you get a Sony laptop. If you break Linux, you get a Dell. And they aren't necessarily the nicest machines on the lineup, either.
You get the machine *and* a $10000 for the first machine/browser to fall. While Apple machines are nice, $10000 will buy you a few *very* nice Apple kits, even if you exploit Windows first. Given $10000 for 1st price, $5000 for second, you'd expect the contestants to go for the easy one first. They knocked OS X over in a matter of minutes.
Well geez, Apple, Sony, Dell. If you wanted a new laptop, which do you pick? Most people DO like the looks of a MacBook Pro (even the lowest end configuration is still a nice looking laptop). Then likely Sony comes next (their laptops are fairly good looking). Which leaves the Dell, for those who just want a laptop and try to avoid the massive crowds going for the more desirable units.
I'd take the $10000 rather than risking a 2nd place with $5000, thank you.
I can see this being useful for problems that are extremely linear and require extreme parallelization on large quantities of data, but that's about it.
That's the danger: Relying on your own lack of imagination to support your argument. If you cared to google a little you would realize that there are many other areas where RP could be relevant.
Erik Meijer who pioneered the RP push at Microsoft and which lead to the Reactive Extensions for C# and JavaScript (on which the current implementations in Java are based) wrote an article with a thoughtful title: "Your mouse is a database". I could as "so is your finger".
The idea is that a mouse is a series of "rows" with mouse positions and button states. Instead of viewing them as series of *events*, RP views them as streams of objects. That allows you to apply filters, actions, transformations etc.
Suddenly, the events become *composable*.
Think of a touch interface. The touch surface fires events. But if you view the events as streams of objects you can define filters and transforms which let only certain "events" through, like a stream which accepts objects starting/resetting at the "touch" but only accepts messages as long as they describe an ever longer diatance in a certain direction until the finger is lifted again. Now you have a composable stream of "flicks". You can define similar streams which will filter/generate circular moves, pinching with 2, 3 or 4 fingers.
Think of the problem of cache eviction. You can define sweeping/eviction algorithms as (simple) streams.
Think of asynchronous programming in a web browser. Parred with web sockets (or in.NET the awesome SignalR which uses web sockets but automatically falls back to other channels when web sockets are not available) you can build responsive, asynchronous interfaces where you *declare* what should happen as server messages are received.
Think of a dealer system where the dealer wants to track certain papers, positions, rates. RP enables you to build a chained, composable filter where alarms are raised (alarms being messages on streams) when a rate changes more than a certain percentage within a given time period.
I've done this 'methodology' many times using Excel.
Sure. Haven't we all?
It also uses a *lot* more ram because you are now maintaining a permanent block of memory for every single operation, for every different piece of data you are coding against.
Not neccesarily . In.NET, Reactive Extensions are integrated with LINQ. As a supplement to IObservable, Reactive Extensions also define IQbservable (a *queryable* observable). Analogous to LINQ for IQueryable, LINQ applied to a IQbservable is actually capable of combine criterias and transformations "up the chain" all the way to the source. I.e. if the "event" source is capable of filtering/transforming - like a SQL database or a RSS based web feed is - LINQ for Reactive Extensions can apply the filter very early in the chain and avoid uneccesary progression of objects which would be masked later anyway.
Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?
It is not just you. There a scores of other people out there who have always done it before 20 years ago.
Grow up. Sometimes Computer Science does see advanced. Realizations. Erik Meijer did an awesome job with Reactive Programming. He found a *duality* between actively "pulling" objects from sequences and reactively receiving "pushed" objects from a source. Given the mathematical duality he even managed to find places where the LINQ pull model was not complete yet.
Reactive Programming is not new. Nor was OO when it really took off. OO actually was don back in the 1970ies with Simula (IIRC). But now RP has *matured* as
So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code:)
You fall into the trap of trying to find reasons for how it is *not* a problem. But *every* single time a weakness is found it opens up to multiple different attacks. Just because you cannot imagine a possible attack using a vulnerability does not mean that such attack vectors do not exist.
Case in point: During the total pwnage (rootkit installed and active for the better part of a month - possibly longer) of kernel.org and multiple other Linux Foundation sites back in 2010 (we still have not seen a post mortem on that, despite promises of openness), the SHA1 digests were quoted as the reason we should not worry of compromise. A weakness where an attacker could create something else with the same digest opens up the possibility for injecting malicious code into the repo.
Assuming that SHA1 weaknesses do not affect something like Git which relies on digests in almost every operation strikes me as naive. Of course Git will have to move off SHA1 just like everyone else. No rush just now - but it would be stupid not to start planning for it.
Holy cow, your fanboy hat must be cutting off the flow of blood to your brain. Explain again why an OS with 4x the market share garners 100x the exploits?
Attackers will *always* try to attack the biggest target. They are not for equal opportunity, they do not meet to work out quotas so that OSes gets attacked accordingly to their market share.
Say you joined a shooting competition: You can shoot at two targets, equal size and equal distance, no objective difference at all. Only difference is that each time you hit target A four people will give you $10 each and each time you hit target B only one person give you $10. You have 10 rounds. How do you distribute your rounds between the two targets? Do you fire 8 shots at target A and 2 shots at target B because that would be the most fair thing to do, or do you fire all 10 shots at target A?.
Maybe, just maybe, there's more to it than market share.
There might be. When you see people start taking shots at B, despite the higher reward of hitting target A, you can conclude that some factor causes them to *not* go for the higher reward. Somehow target A must have become harder to hit, the reward is going down or the shooters skills allow them to hit target B more easily.
But all other things being equal, prudent attackers who are in it for the rewards will go for the higher market share, every time.
Slashdot Mirror
Windows SteadyState from Microsoft is available for Windows XP.
SteadyState virtualizes the OS directories transparently on the disk. File writes/updates are directed to a secluded area. You can set it to simply delete those journaled updates upon restart/signoff. Any malware will be effectively gone. Windows Update would still be possible when signing in as the SteadyState administrator (creating an updated image), but that's kind of moot at this point.
Is that why Windows and IIS got hacked all the time while Linux and Apache/PHP very rarely ?
Citation needed.
Because it had better security ?
Yes, Windows servers are compromised less because it is far easier to set those up securely. Especially IIS+ASP.NET is way more secure than Apache+PHP in almost any way; not least the programming model where PHP almost encourages SQL injections and XSS where with .NET/MVC it is hard to create SQL injections and XSS vulnerabilities.
There was a project for Linux kernel that gives advanced ACL capabilities to Linux systems. I forgot the name of it now, but basically.. whatever was possible to do, you could do it.
ACLs are available with most distros nowadays. However, the point is they are bolted on. They represent a MAC model which competes with simplistic linux file system permissions. You do not switch to ACLs, you turn them on and have to manage them in parallel with regular file system permissions. Thus they complicate the security model rather than refine it (and they still support inheritance pretty poorly). Now throw in SELinux, SUID root utilities and *nobody* stand any realistic chance of performing a reliable security assesment of a Linux system.
There are hundreds of projects that you can add and use.. (stable, tested projects).
The problem with security is an admin that thinks blocking port 22 is gonna keep him safe... if he uses Linux, and the other problem with security in general... is using Windows.
The other problem with security is management hiring idiots (above mentioned jolly bunch, block port 22 and all ok) and/or outsourcing administration to cheap indian companies that work for peanuts.
Coming from someone who cannot remember the "project" with (and obviously does not use) ACLs. Nice.
The best locks in world, which Linux does come with, do not help if the door is left unlocked.
Microsoft OTOH has no doors.
The biggest threat to linux in the last five years has not been the architecture of linux
The biggest threat to Linux security is the number smug, amateurish Linux admins who believe they are all safe because their tribal platform is blessed with magic fairy dust that makes vulnerabilities un-possible.
On the architectural level, the biggest threat to Linux is the outdated security model inherited from the 1970 where saving a few bytes at the expense of better layered security was all the rage. This is exemplified by:
* The woefully outdated permission model where proper ACLs had to be bolted on, and to this day competes with and confuses security planning and auditing (Windows NT had ACLs from the start).
* The fact that only the file system objects were considered for access control. (In Windows the security model extends to all objects: Threads, processes, synchronization objects (locks, semaphores), sockets/ports etc)
* Security tokens do not exist. Instead of granular tokens you have to use "effective users" - breaking the Least Privilege Pinciple (Windows NT was designed with granular process tokens from the start).
When creating a new IIS in Windows, the site is automatically set up with the most restrictive isolation. You do not even have to create a user for the site to run under - the security model already knows about identities and each site gets it own identity which must be explicitly granted permissions to read the file system.
but the willingness of programmers, in particular weak programmers from the WIndows world coming over and applying the same philiosophies to linux development.
That's rich. The absolutely most security-ignorant ecosystem is the LAMP community. PHP with it's abysmal security record is the worst language *ever*.
One project might use "customer" another "client" or "businessname". Each of these may have a "description", "overview", "synopsis" and a "type"/"kind"/"businesstype" field.
So code discovery of data doesn't work unless we have agreed to standardized field names in advance
Why doesn't it work? Have a look at $metadata. You get schemas for your data. OData has full discovery. The only "standardized field name" you need to know in advance is $metadata.
... but now there's always exceptions to look out for and name conflicts.
Now even if we know the names of every field, how do we know exactly what sort of data will be returned? A name alone is nothing unless we can ensure its type, and remove all assumptions about what it can contain.
OData was originally designed for XML. JSON was added later. With XML you can (and should) use namespaces to disambiguate field names between different entities/domains.
W3C was something a committee did which was academic. Only Netscape and MS specific CSS and HTML mattered and websites needed to include specific workarounds for one or the other etc. Man, people forget how dark the web was 10 years ago.
This. And everyone seems to have forgotten how Netscape pushed the awful JSSS as an alternative to CSS. Microsoft actually pushed CSS at the time.
At the time, the best browser actually won. It was the neglect by MS in the years following that was/became the big problem, one for which MS has rightfully earned a lot of scorn. MS never wanted the web to evolve too fast as it could undermine the very lucrative desktop business.
But at the time of Netscape/MS rivaly, it was actually Netscape who tried to foist abominations like JSSS and the "layer" tag upon us.
You're an idiot as standard users still have access to threads, processes, and the file system. This means you can attach a rogue process or malware to an admin one which happens to run as a service. It can then be executed with full admin privileges.
Nope. A standard user (which even includes admins who have not elevated through UAC prompt yet) can only attach to processes running under *the same* account as itself, and then only to a process/thread within the same *session* as itself.
In Windows, all services are launched in a separate session from the shell - meaning that direct attachment is not possible from a user shell to a service - even if they are running as the same user.
Unlike *nix'es, Windows uses proper tokens. What a process is permitted to do is not limited by a user account - rather each process has its own fine-grained token. By default a process inherits the token from the process that spawned it - but it can be further limited. When you log in, the shell process is created with a token which has all administrator privileges stripped from it and which runs with medium integrity level. So even if you are an administrator you will still get a standard user token. Upon login another token was also created - one which has high integrity level and has not been stripped of administrative privileges you may hold.
When you launch a process where the manifest demands elevated rights, Windows will issue the UAC prompt. If you accept then you get to run the process with your "super" token. This prompt is running with "high" integrity level (and by default even on a separate desktop) to prevent malicious processes already running as you from "remote controlling" the prompt at click the ok button for you.
It is important to note that unlike on Unix where you elevate to "root" with sudo - and thus receive privileges far beyond what is called for - Windows UAC prompt *can not* grant you privileges you did not already hold (well - if *another* user authenticates at the prompt you can "borrow" that users privileges).
It is worth noting that while all browsers were successfully attacked, the "Unicorn" class challenge Windows 8.1 x64/IE11/EMET was *not* exploited - even though it would have netted the attacker a cool $150,000.
It is broken by design because sudo protects the utility used to access the protected resource rather than protecting the resource itself.
Relying on and allowing such a mechanism does two things to your security model:
1) It forces users with otherwise legitimate access to go through specific utilities (actually fire up processes) just to access a they should have access to in the first place.
2) Worse, it takes away your ability to assess who has access to the resource. Since there are multiple SUID root utilities on the system, and multiple sudo utilities with sudoers config, you really have to know the capabilities of each of those utilities to know that they cannot be used by an unauthorized user to access the protected resource.
Had you used a system where the resource was protected and where there were no sudo/SUID bypass mechanism available, you can generate a report of users with access to the resource simply by querying the user/group permissions. As an added benefit, anyone with legitimate access could then access the resource and not be forced fire up a process and to go through a specific utility to access the resource.
Not only is the sudoers 144-page-incomprehensible, the whole idea is broken to begin with:
First, you design a simplistic security model where a single user/group (root) is hardwired to a number of privileges not available to anyone else and where standard users' privileges are inherently too limited.
Then you start drilling *holes* (big holes) because the model clearly does not meet real world requirements. SUID lets users run as root for the duration of the process. A single escape during the processing will allow the otherwise non-privileged user to drop up to a root shell. A single memory corruption may allow the user to run unrestricted as root. And there has been *many* such exploits in all variants of Unix, including Linux, OS X etc.
Because the operating system security model did not allow fine grained access control to resources, someone came up with the idea to protect the *utility* instead of the resource or system function (and took out a patent, no less) . WTF? Why does the OS not protect the syscall to change system time or change password? Why did they design a system where you would need to start a frigging SUID root process to do that?
It is a direct violation of the least privilege principle, one of the core security principles. Every time you let someone invoke sudo you let them run as root and just hope that the utility does not contain vulnerabilities, because the *consequence* of a vulnerability is total system compromise.
sudo is a design flaw in the ActiveX class. In fact, they are really very much alike: In both cases you hand over the keys to the house and cross your fingers that the visitor is well behaved while he is in there.
Once the holes have been drilled, sudo (and SUID roots) make it extremely hard for security auditors to assess whether the security has been set up with meaningful barriers: They can not audit a resource and determine who has access to view or change it. The sudo / SUID model always leave the possibility that some utility allows another access to the resource. I.e. the auditor cannot assess a single resource, rather he must assess the system in its entirety. And when doing that he must also trust that the SUID root utilities and sudo utilities are what they pretend to be, i.e. he must validate the utilities as well; or accept the possibility that one or more of the utilities is actually capable of more than it advertises.
Had the designers opted for a proper model where resources (processes, syscalls, devices, ports) were actually protected by access control lists, the auditor could have audited the security settings and remain confident that there was not some *other* way to access the resource.
The SUID root / sudo idea was a terrible one. It was necessitated because of an woefully inadequate security model. Rather than fixing the model (like e.g. create real tokens with claims) the designers decided to drill holes. Many holes.
Good for individual commands, but not for learning the syntax. That's the bit that stumps me.
man syntax
system responds with 2 topics: about_Command_Syntax and about_Path_Syntax
man command_syntax
system responds with help "about the command syntax".
and the fact that some syntaxes work on some commands and not on others annoys me.
What are you talking about? PowerShell commands are extremely consistent - not like the different syntax conventions used for ls, find, xargs and dd - just to name a few examples of Nix inconsistencies. PowerShell commands always follow the pattern Verb-Noun. A limited set of verbs are strongly encouraged (to the point where a command author has to bend over to break the convention) and their conventional uses are explained in command author guidelines. While PowerShell commands may take positional parameters they *always* have a name (the position is optional to allow for a short form). Parameter names are *always* specified using dash (like -ParameterName). Parameter names can be shortened as long as they are still unambigious. This is all a feature of the *shell* - parameter parsing is not left to each command, i.e. a command is forced to use the consistent scheme.
I would like a good but brief overview of how powershell commands are actually structured without having to go through a massive Microsoft Press book
From running man command_syntax:
TOPIC
about_Command_Syntax
SHORT DESCRIPTION
Describes the syntax diagrams that are used in Windows PowerShell.
LONG DESCRIPTION
The Get-Help and Get-Command cmdlets display syntax diagrams to help
you construct commands correctly. This topic explains how to interpret
the syntax diagrams.
Syntax Diagrams
Each paragraph in a command syntax diagram represents a valid form
of the command.
To construct a command, follow the syntax diagram from left to
right. Select from among the optional parameters and provide values for
the placeholders.
Windows PowerShell uses the following notation for syntax diagrams. ....
(explanation of syntax, parameters etc. follows).
You really only have to look for it.
The problem isn't GUI users, its the fact Powershell is complete shite.
All this time I cant get a basic instruction on how Powershell works without getting a 500 page book. Learning Linux and AIX wasn't this hard (granted the Linux training covered a lot of the AIX ground).
Try typing man. That should get you started. :-)
You can start by knowing only 4 commands. Everything is discoverable through those:
* Get-Help (aliases help, man): Get help for a command or for a topic, e.g. "man ls" gets help for the "ls" command (ls being alias for get-childitem). Try typing man about - that'll give you a list of "about" topics that explain PowerShell quite nicely.
* Get-Command (alias gcm): Lists available commands.
* Get-Member (alias gm): Lists available members on items output from a command, e.g. ls|gm will tell you that ls produces DirectoryInfo and FileInfo objects each with an extensive set of properties such as name, path, length, access time etc.
* Get-Alias (alias "alias"): Lists defined aliases. Several aliases help Nix users get started, e.g. "ls", "ps".
Does that matter? With code pages marked as read-only and data pages marked as no execute is it even possible to turn such a buffer overflow into an exploit other than DoS any more?
Yes it is. The technique is referred to as "return oriented programming". That is why you need strong ASLR to make DEP/NX effective. Windows and OS X (IIRC) are the only OSes with strong and complete ASLR.
Huh, and I suppose you wrote the Powershell out in the longer way just by coincidence? While that longhand version might be better in a script for documentation purposes, it's way more verbose than is needed for a quick cmd-line run.
While it is generally true that using the longer versions of cmdlet names and parameter names and using named parameters instead of positional ones increases readability in scripts, this specific "longer version" is just stupid. It has been artificially made longer and more complicated and has actually *lost* readability bc of that process. One can only guess to the intentions behind that "example". It is certainly very, very bad PowerShell.
In fact, (...googling...) it looks like there are network-adapter cmdlets in server 2012 and win 8.1 so it may just be a matter of upgrading PS.
Yes. In fact, the functions from the NetAdapter module has been automatically created as wrappers from WMI objects.
PowerShell: Get-NetAdapter | select macaddress /sbin/ifconfig | grep -Eo ..\(\:..\){5}
Bash:
Which is shorter?
Which is more readable?
Which is more robust against changes (like new properties/columns)?
Which is more consistent across related commands?
Which is more discoverable?
Which is more extensible?
Note how the PowerShell version does *not* need to engage in string parsing, and how it does *not* need to rely on specific file content formats. The advantages of objects in the pipeline.
Btw, if you want PowerShell to output in the same metadata-stripped format as from bash/ifconfig, you can make the PowerShell command even shorter, without sacrificing readability:
PowerShell: (Get-NetAdapter).macaddress
Powershell was designed to market Windows server, providing something that looks familiar to Unix/Linux admins. It's by no means a replacement for VBScript. (Which is *not* the same thing as VBA.) VBScript, being COM-centric, is uniquely suited to accomplishing all sorts of tasks on Windows. It just happens to be getting "deprecated" as part of Microsoft's overall strategy: They want to attract people to Windows server while converting "civilian" Windows into virtually a kiosk OS.
Sorry, BS. PowerShell is a foundation technology in Windows, unlike VBScript. Since Windows 7, the troubleshooting packs are actually written in PowerShell! The troubleshooting utilities are automatically launched by the system when e.g. network problems occur.
PowerShell is every bit as COM capable as VBScript. PS uses a "unified" type system where multiple object models (COM, .NET, WMI etc) are surfaced as common PS objects.
VBScript is definitively legacy (and deprecated). I will actually wager a bet that there is not a single meaningful VBScript that could not be written shorter and more elegant with PowerShell.
I pasted (18*(567/23))+67 into the powershell prompt:
PS C:\Users\Me> (18*(567/23))+67
510.739130434783
PS C:\Users\Me>
That's brilliant!
It is object oriented so the data transfer between processes is more robust. Also all the commands' manual pages come with extensive documentation and lots of great examples. UNIX man pages usually lack examples.
Most bashers (no pun intended) miss several aspects of PowerShell simply because they view it as just another shell.
One such aspect is the fact that PowerShell is designed to operate directly with an application's core logic (the object model) whether that application was designed using COM or .NET. Virtually *all* of Window's features and even 3rd party applications for Windows are designed using one of those models. So the barrier to exposing the functionality to the CLI (PowerShell) is really, really low, and even older applications that predates PowerShell or that were never designed for PowerShell (like iTunes) lend themselves to CLI manipulation. Forget about needing to craft a suite of external CLI tools - your app is inherently exposed to command line manipulation.
Another often overlooked aspect is how PowerShell is designed to run in-process within an application. The CLI is just *one* possible host for PowerShell. Alas, you can add the PowerShell engine to your app and immediately leverage existing commands to manipulate the in-process memory objects of your application. So not only is it *easy* to expose your application to automation, you can actually take advantage of the PowerShell engine to save work for your own in-application automation. With workflow engine integration in PowerShell 3.0 (it is now at 4.0) this is a great way to orchestrate workflows activities in an easy-to-manage way.
app-based network transparency is a feature of RDP. It hasn't been implemented in Windows as far as I know of but I'm optimistic that Wayland's proposed reliance on RDP for network applications will implement it per-app rather than full desktop.
It has been available for several years now. It is used in App-V to access applications running on a server but displaying it'a GUI in windows on the local machine. I don't think you can use app-based RDP in a client Windows to client Windows configuration, though.
I sincerely apologize for the harsh tone. That was uncalled for, and I shot off without reading what I wrote and how it comes across. Again, I apologize.
Like you I have some "triggers". One of my triggers is blanket dismissal. I think what I perceived as your blanket dismissal was what triggered. You are correct about Ruby-on-Rails. It turned out that it was not up to the job. But at the same time it *did* popularize the "web-MVC" pattern in a way that Java frameworks (e.g. Struts) never achieved.
When someone praises a new technology as the new "best thing since sliced bread", we should approach it with a healthy portion of skepticism. However, we must also keep our minds open to new advances.
Reactive Programming is not an alternative to OO or FP. It complements both, and at the same time it promises to make certain aspects much more manageable, like e.g. asynchronous and parallel processing.
As for Pwn2Own, the results really are meaningless - if you break OS X, you win a MacBook. If you break Windows, you get a Sony laptop. If you break Linux, you get a Dell. And they aren't necessarily the nicest machines on the lineup, either.
You get the machine *and* a $10000 for the first machine/browser to fall. While Apple machines are nice, $10000 will buy you a few *very* nice Apple kits, even if you exploit Windows first. Given $10000 for 1st price, $5000 for second, you'd expect the contestants to go for the easy one first. They knocked OS X over in a matter of minutes.
Well geez, Apple, Sony, Dell. If you wanted a new laptop, which do you pick? Most people DO like the looks of a MacBook Pro (even the lowest end configuration is still a nice looking laptop). Then likely Sony comes next (their laptops are fairly good looking). Which leaves the Dell, for those who just want a laptop and try to avoid the massive crowds going for the more desirable units.
I'd take the $10000 rather than risking a 2nd place with $5000, thank you.
Are there any examples of real-world reactive databases in production or development?
yes: http://technet.microsoft.com/en-us/library/hh750618(v=sql.10).aspx
I can see this being useful for problems that are extremely linear and require extreme parallelization on large quantities of data, but that's about it.
That's the danger: Relying on your own lack of imagination to support your argument. If you cared to google a little you would realize that there are many other areas where RP could be relevant.
Erik Meijer who pioneered the RP push at Microsoft and which lead to the Reactive Extensions for C# and JavaScript (on which the current implementations in Java are based) wrote an article with a thoughtful title: "Your mouse is a database". I could as "so is your finger".
The idea is that a mouse is a series of "rows" with mouse positions and button states. Instead of viewing them as series of *events*, RP views them as streams of objects. That allows you to apply filters, actions, transformations etc.
Suddenly, the events become *composable*.
Think of a touch interface. The touch surface fires events. But if you view the events as streams of objects you can define filters and transforms which let only certain "events" through, like a stream which accepts objects starting/resetting at the "touch" but only accepts messages as long as they describe an ever longer diatance in a certain direction until the finger is lifted again. Now you have a composable stream of "flicks". You can define similar streams which will filter/generate circular moves, pinching with 2, 3 or 4 fingers.
Think of the problem of cache eviction. You can define sweeping/eviction algorithms as (simple) streams.
Think of asynchronous programming in a web browser. Parred with web sockets (or in .NET the awesome SignalR which uses web sockets but automatically falls back to other channels when web sockets are not available) you can build responsive, asynchronous interfaces where you *declare* what should happen as server messages are received.
Think of a dealer system where the dealer wants to track certain papers, positions, rates. RP enables you to build a chained, composable filter where alarms are raised (alarms being messages on streams) when a rate changes more than a certain percentage within a given time period.
I've done this 'methodology' many times using Excel.
Sure. Haven't we all?
It also uses a *lot* more ram because you are now maintaining a permanent block of memory for every single operation, for every different piece of data you are coding against.
Not neccesarily . In .NET, Reactive Extensions are integrated with LINQ. As a supplement to IObservable, Reactive Extensions also define IQbservable (a *queryable* observable). Analogous to LINQ for IQueryable, LINQ applied to a IQbservable is actually capable of combine criterias and transformations "up the chain" all the way to the source. I.e. if the "event" source is capable of filtering/transforming - like a SQL database or a RSS based web feed is - LINQ for Reactive Extensions can apply the filter very early in the chain and avoid uneccesary progression of objects which would be masked later anyway.
Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?
It is not just you. There a scores of other people out there who have always done it before 20 years ago.
Grow up. Sometimes Computer Science does see advanced. Realizations. Erik Meijer did an awesome job with Reactive Programming. He found a *duality* between actively "pulling" objects from sequences and reactively receiving "pushed" objects from a source. Given the mathematical duality he even managed to find places where the LINQ pull model was not complete yet.
Reactive Programming is not new. Nor was OO when it really took off. OO actually was don back in the 1970ies with Simula (IIRC). But now RP has *matured* as
Actually, they didn't. They have a way for Visual Studio to control what you do in Azure, as the article says:
"developer services that run on Windows Azure, and extends the capabilities of Visual Studio"
Actually, they did. Although "full-fledged" is probably a stretch when one thinks about Visual Studio. And it was only released as a preview.
This is a screenshot of the in-browser editor, complete with IntelliSense, Solution Explorer etc.
Videos of the beast at Channel9.
Nice example of insecure code at their login screen (http://go.microsoft.com/fwlink/?LinkId=309297&clcid=0x409&slcid=0x409):
What if InsertOrUpdate() or Save() fails? Lesson number one in secure programming: ALWAYS check return codes of functions.
I'm curious, in which lesson do we learn about security boundaries and contexts?
If you are such a security expert, please tell us why would you expect to find security assertions in client-side JavaScript code?
I can tell you that security decisions should never be performed client-side, and you expectation to find such code is utterly revealing.
So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code :)
You fall into the trap of trying to find reasons for how it is *not* a problem. But *every* single time a weakness is found it opens up to multiple different attacks. Just because you cannot imagine a possible attack using a vulnerability does not mean that such attack vectors do not exist.
Case in point: During the total pwnage (rootkit installed and active for the better part of a month - possibly longer) of kernel.org and multiple other Linux Foundation sites back in 2010 (we still have not seen a post mortem on that, despite promises of openness), the SHA1 digests were quoted as the reason we should not worry of compromise. A weakness where an attacker could create something else with the same digest opens up the possibility for injecting malicious code into the repo.
Assuming that SHA1 weaknesses do not affect something like Git which relies on digests in almost every operation strikes me as naive. Of course Git will have
to move off SHA1 just like everyone else. No rush just now - but it would be stupid not to start planning for it.
Holy cow, your fanboy hat must be cutting off the flow of blood to your brain. Explain again why an OS with 4x the market share garners 100x the exploits?
Attackers will *always* try to attack the biggest target. They are not for equal opportunity, they do not meet to work out quotas so that OSes gets attacked accordingly to their market share.
Say you joined a shooting competition: You can shoot at two targets, equal size and equal distance, no objective difference at all. Only difference is that each time you hit target A four people will give you $10 each and each time you hit target B only one person give you $10. You have 10 rounds. How do you distribute your rounds between the two targets? Do you fire 8 shots at target A and 2 shots at target B because that would be the most fair thing to do, or do you fire all 10 shots at target A?.
Maybe, just maybe, there's more to it than market share.
There might be. When you see people start taking shots at B, despite the higher reward of hitting target A, you can conclude that some factor causes them to *not* go for the higher reward. Somehow target A must have become harder to hit, the reward is going down or the shooters skills allow them to hit target B more easily.
But all other things being equal, prudent attackers who are in it for the rewards will go for the higher market share, every time.