The point is that something developed in the open is often unfairly punished here, as although the betas/nightlies are quite clearly marked "use at your own risk", and only intended to be used by appropriately clued up people, vulnerabilities in them are still disclosed even tho they are generally of no consequence.
Not unfair at all, as bugs found during beta are not assigned CVEs. They never become "official" vulnerabilities. CVEs only track vulnerabilities in released software.
One example would be http://www.phreedom.org/solar/exploits/msasn1-bitstring/ [phreedom.org] There was a disclosed vulnerability in the microsoft asn.1 library, but the patch for it brought along a fix for another vulnerability in the same library that was not disclosed. This vulnerability was subsequently found by third parties, who produced and released a working exploit forcing microsoft to admit to the vulnerability several months later.
What you have is evidence that a code change Microsoft did also removed another vulnerability. That could very well be a side-effect of simply fixing the first bug by cleaning up the algorithm. It does not demonstrate that Microsoft knew about the bug in the first place.
The exact same thing could happen with any other software. When Mozilla fixes a bug in in a rendering algorithm by re-implementing it, I could also claim that they silently fixed *other bugs* within that algorithm, even if they were not recognized at the point. We wouldn't assume malice on part of Mozilla for that.
Or consider how Microsoft re-implemented TCP/IP for Vista. Does that mean that they silently fixed all bugs which from that point were found in the old stack? Silly.
Firefox reports every vulnerability discovered, even those discovered in alpha and beta versions (which is a normal function of beta testing)...
They report them in the open, but they are *not* considered vulnerabilities of released software and they are not reported as such to NVE or Mitre and they are not assigned CVEs. You cannot find any CVE referring to a beta or alpha version of FF.
By contrast, commercial software is rarely available to the general public at all until a late beta stage, bugs found and fixed during the early development phases will never be disclosed to the public
Yes, well, when it is not available any security bugs found during the testing/security push don't matter, do they? I mean, I expect the vendor to make a security push, reviews and fuzzing during both development and testing. The final product which is released is what should be judged.
Commercial companies, not just browser makers, generally only admit to vulnerabilities which have (or are threatened to be) independently published, because admitting to vulnerabilities is bad for business and not something any for-profit company would do if they have the chance not to.
And you have proof of this. Or is it just speculation. Many vendors have a customer base who rely on the vulnerability disclosures being accurate. That is why the disclosures have to be accurate. A customer looks at the patch and based on which product/part it patches (is the part deployed, is it critical, is it exposed) and the description of the vulnerabilities being addressed (would they pose a risk to the customer) they decide whether to patch their systems or skip it and prioritize stability.
While vendors may have a small interest it keeping the CVE count low, at least some of them have a bigger interest in serving their existing customers with reliable information with which they can make informed decisions. The latter is *much* more important to at least MS than the former.
In other words, it is *not* in MS own interest to sneak in vulnerability fixes without disclosing them. Doing so would put their customers at risk of making uninformed and potentially dangerous decisions. Imagine the outcry if MS sneaked in a fix which were not applied by customers because they decided that the *disclosed* vulnerabilities did not pose a risk.
CVEs - taken over a period of time - actually *is* a good measure of the quality control process of the vendor. Microsofts security focus following the disasters at the beginning of the century is starting to pay off. Mozilla is the new insecure bloat. Well, and Adobe. And Java.
An even better defence against such attacks, is Apple's model... If you can't install/execute anything that's not come from a trusted source, social engineering simply isn't going to work...
To be fair a white-list has been possible on Windows since (at least) Vista. This has been beefed up at little with Windows 7 / 2008R2. Security policy settings allow an administrator to enforce a number of rules, such as path rules, network zone rules, hash rules and certificate rules.
The certificate rule is rather advanced and based on authenticode. Basically an admin can set up rules for specific vendors or all vendors where the code has been signed using a certificate from a trusted set, i.e. through trust of a root cert. For instance you can set up a rule which requires all executables to be signed using a certificate issued by a trusted root (Verisign) and then white-list vendors such as Microsoft, Adobe (if you dare), Apple (if you dare) etc.
The network zone rule is also interesting because it can restrict software based on where you've got it. The zone from where you downloaded the software is stamped into an alternate datastream on downloaded files. The policy can then deny execution of anything coming from the Internet or even the local intranet.
An even better defence against such attacks, is Apple's model...
A whitelist approach certainly has its advantages - securitywise - to a blacklist (reputation) approach. However, in the case of Apple you get the distinct feeling that in also coincides with their strangehold on the revenue stream. With a white-list approach you give up freedom and convenience. In the case of iOS you subject yourself to the whim of Apple. Some don't see a problem with that. Personally, I think it interferes with the computer as a general-purpose device. However, as computers (and phones in particular) are becoming commodities I can certainly see the allure of the white-list.
However what i will say, is that there should be a good selection of such systems, each operated by different gatekeepers. Having a single monoculture is a very bad thing.
Very good point. I have pondered that myself. A system a little like SSL certificates or domain authorities. It is not without problems, though. For one thing, it would kill "free" software on those devices. I don't suspect that an approval (code signature) will be given away for free. After all, the reputation provider takes a risk every time they issue a signature. If they let themselves be fooled their own reputation may be on the line. And then there's the risk of rogue reputation providers just like payment processors. Russia, looking at you.
Since people don't tend to read the article (much less the NSS Lab's purchased findings that were mislabelled as a study)
So did you read the study? Did you come across the following section?
This report was produced as part of NSS Labs’ independent testing information services. Leading vendors were invited to participate fully at no cost, and NSS Labs received no vendor funding to produce this report.
Actually, this is a running study, so it also reflects the speed by which the browser vendors update their respective reputation databases. Some 85 new urls were entered on average each day (after being confirmed as malware-serving urls) throughout the quarter. NSS releases these results each quarter.
You have a valid point about the sandbox - but the study doesn't really do security a justice, when comparing the browsers.
Malware is seldom a browser injection issue, but is instead vectored through plug-ins (I'm looking at YOU, Adobe!) which are privileged at a higher-level than the "sandboxed" container application.
No. These days some 85% of infections derive from social engineering. Malware comes in through the user. Vulnerability exploits seems to be a lot less effective these days. Social engineering is precisely what the tested security (reputation) mechanisms are aimed at.
Having said that, yes, Flash is really, really bad. So is Java. And both are rather prolific, regrettably.
I could deliver extended anecdotes about the 0-day flash and pdf exploits that I've witnessed, unfolding right in front of me... Suffice it to say, fully patched systems with browser sandboxes are not immune.:-)
That piques my interest. When was this? AFAIK there has not been a *single* in-the-wild sandbox breach of neither Chrome nor IE (yes, pwn2own demonstrated a combination of 3 techniques which escaped the IE sandbox - but this has not been reported in the wild). Up until some (fast) versions ago, Chrome did not sandbox Flash. IE did that since IE7.
The combination of security and privacy extensions that are developed for Firefox are, still, unmatched. Ghostery, AdBlock+ and BetterPrivacy will together prevent the opportunity to ever render many of the malicious, content delivered exploits. They also serve to screen and scrub the most pernicious of web-threats: covert bugging and monitoring of the browser by a third party.
Whether they are unmatched is a matter of opinion. Firefox requires addons and will block more broadly (which is desirable to some). To me, the fact that FF code quality seems to lack (they have had most vulns reported for the last 5 years going) combined with their nonsensical refusal to implement a sandbox makes it a no-go for me. (I'm, using Chrome, btw).
You can also query Secunia for vulnerabilities. With the new version number scheme and ultra-fast previous versions retirement (where you are left vulnerable if you don't upgrade immediately), you'll have to grok the numbers somewhat. Basically count the *unique* CVEs affecting all FF versions since -say FF3.5. Do the same for IE8&9. You will not like the result.
Firefox is the only major browser that openly reports vulnerabilities so of course it is going to have the highest publicly countable number.
BS. All the major vendors are obligated to report vulnerabilities through Mitre. All browser vulnerabilities are assigned unique CVEs.
And even if you had an accurate count of known vulnerabilities from the other vendors, known vulnerabilities hardly equates to total vulnerabilities, even less so when every vulnerability is counted as equal to every other one.
If you consider a set of browsers which must be assumes to receive an equal amount of scrutiny (IE,FF,Chrome), if one browser year after year comes out with most vulnerabilities, surely that does say something about code quality.
This report was produced as part of NSS Labs’ independent testing information services. Leading vendors were invited to participate fully at no cost, and NSS Labs received no vendor funding to produce this report.
Firefox still does not have a sandbox in place. That right there is a severe problem. Especially as Firefox is *the* browser with most vulnerabilities. The only thing Mozilla has going for Firefox security is that they are really fast to patch once a vulnerability has become known.
Don't run bad code as root, and certainly not as a persistent server. Setuid servers are pretty much a thing of the past anyway.
Eh? Setuid servers are at the centre of sudo and sudoers. In reality sudo is a kludge designed to protect an inadequate and dangerous security mechanism and to mitigate the need for everyone to know the root password. Nevertheless, the stupidity of setuid was brought about because of an initially inadequate security model. A security model where only root could perform certain functions and if anyone else had a legitimate need to perform those functions they had to become root at least temporary. Because only root may perform those tasks.
Look up the KISS rule. Complex security rules that humans can't understand make security worse not better. ACLs result in scanning though lists to match rules which kills performance. Cleaner is better.
KISS is fine. When it is sufficient. When it becomes too simplistic it becomes just stupid. Me-us-world is clearly not sufficient beyond a single user system. Unix file permissions was conceived in the permissive research/education environments of the 1970ies. The problem is that now there are multiple “us”. Proper ACLs are a requirement for government and business certifications these days.
ACLs result in scanning though lists to match rules which kills performance. Cleaner is better.
Ah, but the Windows designers thought of that, you see. That is where the object-oriented handles come into play. In Windows you access objects though handles not syscalls, be it processes, files, directories, registry entries, TCP ports etc. When you open a handle you request a certain access. If you request a given access (and it is granted), the corresponding method of the handle is mapped to the actual function. If you didn’t request a certain access the corresponding method (say, “modify”) is mapped to a “denied” method. When you later invoke operations on the handle, the operation is mapped directly to the method entry. No access check takes place at this point because that was all resolved when the handle was opened/created.
Inheritance of security makes a complex mess more complex and impossible to understand. Look up the KISS rule. You clearly don't know anything about groups or the effects of setgid on directories either.
Inheritance allows admins to achieve sensible security by default, like when they set a web site directory tree to be readable by account under which the web server runs. They allow the web server account read access and sets it to be inheritable. That way the admin of each site can create new directories (under his own account) and the webserver can still serve the files. And yes, inheritance can be broken if the web site admin wants to restrict access to a sub tree.
Not strictly true as root can be separated into capabilities.
Not strictly true? How about just true? Root can not be “separated” into capabilities. The check for uid 0 is hard coded into the system and will allow root to do *anything* without questions asked and often without audit logging. True, Linux has defined capabilities which can be assigned to non-root users. Use them much? Last time I checked my Ubuntu installation not a single utility had been assigned a capability instead of setuid.
So how does the limits on what 'administrator' can do help when there are countless exploits that give system level access?
Strawman. Privilege escalation bugs have been found in every OS. Does that mean that we should just abandon security? Do you have any data (beyond your belief system) that this is more common in non-Unix/Linux systems?
It's possible to change the permissions, capabilities, or chroot a process. You don't seem to know wha
... because they started with a solid proven design, UNIX. Microsoft never had that advantage.
Yeah, good UNIX proven design
Like setuid servers (not!) where even simple bugs allow an attacker direct root access
Like the hopelessly inadequate me-us-world security coarse-grained security which requires proper ACLs to be bolted on top.
Like you cannot set up proper inheritance of security from parent folder, leading admins to design strange processes to wake up and chmod files.
Like the almighty root to rule them all. No separation of duties there. (Windows has proper separation of duties based on privileges. Even admin does not own all privileges, for instance the admin *cannot* write to or clear the security log).
Like the UNIX idea of a "token" which are just UIDs hard-wired to user accounts. (Windows has *real* process tokens which can be manipulated per process, e.g. stripping certain privileges from a process even if it runs under an admin account).
Windows security design is not perfect, but it is a god deal better designed and more capable than the "UNIX proven design". Why do you think SELinux was developed by the NSA? Because Linux with its "proven design" was woefully inadequate for government work - a task for which Windows is certified but only few Linuxes - those with SELinux).
We keep hearing about this "superior" Unix security design. But it is always referred to in the abstract with no details. Maybe it is some magical fairy or Apple dust?
Yes, a good admin can lock down a Linux with apparmor or SELinux pretty tight. Both apparmor and SELinus are solutions which compensates for the initial inadequate design.
I can't really see what sort of functionality you need out of a tcp stack that wasn't already there. Anything else can be bolted on top.
From Windows Internals, Fifth Edition (Mark E. Russinovich; David A. Solomon; Alex Ionescu):
The Next Generation TCP/IP Stack offers several advanced features to improve network performance, some of which are outlined in the following list:
Receive Window Auto Tuning. The TCP protocol defines a receive window size, which determines how much data a receiver can accept before the server requests an acknowledgment. A higher size favors low-latency networks with high throughput, while lower values work better on networks such as Wi-Fi. The Windows TCP/IP stack is capable of analyzing the conditions of a network and choosing the optimal receive window size, adjusting it as needed if the network conditions change.
Compound TCP (CTCP). While automatically changing the receive window size allows more data to be received, CTCP aggressively increases the amount of data that can be sent by a machine, while monitoring bandwidth, latency, and packet loss. Using CTCP on a high-bandwidth, low-latency network can significantly improve transfer speeds. CTCP is disabled by default.
Explicit Congestion Notification (ECN). Whenever a TCP packet is lost, the TCP protocol assumes that the data was dropped because of router congestion and enforces congestion control, dramatically lowering the sender's transmission rate. ECN allows routers to explicitly mark packets as being forwarded during congestion, which is read by the Windows TCP/IP stack as a sign that transmission rates should be lowered. Lowering rates in this manner results in better performance than relying on congestion control. ECN is disabled by default.
High-loss throughput improvements, including the NewReno Fast Recovery Algorithm, Enhanced Selective Acknowledgment (SACK), Forward RTO-Recovery (F-RTO), and Limited Transit. These algorithms reduce the overall retransmission of acknowledgments or TCP segments during high-loss scenarios while still maintaining the integrity of the TCP stream. This allows for greater bandwidth in these environments and preserves TCP's reliable transport semantics
Those of us who are old enough remember the "portions copyright the regents of the University of California Berkeley" (or words to that effect) that used to be part of the Windows legal declarations from 95 onward. It has been considered common knowledge that their pre-Vista TCP/IP stack was taken from BSD, as was their FTP executable
The "common knowledge" here is an euphemism for myth. Back in Windows NT 3.1 (!) MS licensed a TCP/IP stack from Spider. That *may* have been based partially or entirely on the BSD stack of the time. However, as of Windows NT 3.5 and Windows 95 that stack had been replaced by Microsofts own stack. Some of the utilities (ftp client, ping?) were still the original BSD utilities, or based on them. The network stack has not been BSD since Windows NT 3.1.
If you're going to claim otherwise, you should offer some citations please.
Incorrect, it had been previously rewritten for Windows NT 3.5. See above.
But if you were paying attention back during the interminable Vista beta process, you would've remembered the noise about those old TCP/IP vulnerabilities, solved long ago, that Microsoft re-introduced with their new stack.
Citation? or should I write
If you're going to claim otherwise, you should offer some citations please"
Do I understand their presentation correctly? Users in said Enterprise have admin privileges?
No. The point is that *any* device which gets access to a network with OS X server can:
1) Wait to be contacted by OS X server. The server will stupidly identify itself with network-wide credentials (can be used for other hosts) 2) Device under attacker'c control turns around and starts contacting *other* machines using the credentials it has just learned from the server. 3) Other OSX machines will stupidly answer the request and will previde their *own* credentials since you are "obviously" a trusted server. 4) Harvest the acquired credentials 5) Profit.
The "any device" may be a compromised client or a prepared device (notebook?) hooked on to the network through physical or WiFi breach. How is not the point of TFA, it is the potential consequences. A single client/device under an attackers control allows him to harvest the password set.
So long as there is an option for disabling js completely on read, and sand boxing it fully when it is turned on ( something browsers have been doing for years) moving to js and HTML would not make office any less secure, and possibly more secure as rendering js and HTML is a well understood problem.
I believe that Office is already (2010) sandboxing documents. IIRC documents "tainted" with an Internet origin will open in a sandboxed (low-integrity) process.
And Mac OS X explicitly warns you if you are about to open an application downloaded from the Internet. This means that getting someone to run your code requires tricking them (through social engineering) into knowingly launching an application that they've never launched before, as opposed to tricking them into running your code by making it look like a JPEG file of Lindsay Lohan naked or whatever. Maybe Windows 7 does the same thing (I'm not sure), but that was at least historically a big problem on Windows.
In Windows, files downloaded from the internet has the origin written in an alternate datastream. If you execute such a file you get a warning (like in OS X), but then even if you choose to run the executable, it will run with low integrity. Low integrity is part of UAC and sandboxes the process so that it by default has only read access as the current user. Write access (safe a few cache locations) is completely blocked, safe a few safe cache locations. This is a major obstacle for anyone wanting to use a trojan to install malware. He cannot even infect the local user, bar som sandbox escape vulnerability or some more clever social engineering.
Try a contest where the first person to break *any* system gets $10.000 or $15.000. Then you have pwn2own. And then you'll see that the attackers attack the system they believe most vulnerable first. Or they risk someone else does it. What you'd rather have, a MB pro + $5000 or a HP/Dell + $15.000?
The two problems with.NET is that it promised a lot of things that are either false or pointless.
1) Strawman. Microsoft never promised cross-platform..NET was developed when Sun refused to let Java become a viable option for writing native apps. Java always insisted on "virtualizing" the OS - even rendering each pixel of screen widgets. MS rightfully felt that this was offering a sub-par user experience and first tried to worm in the ability to use native widgets - and when that failed they created.NET. Which has P/Invoke which offers a much better integration to the underlying OS than anything Java.
2) False;.NET actually *is* language independant. Unlike Java.NET was designed with this in mind from the start, hence the CLR was always "bigger" (had features not exposed in C# or VB) than any one of the languages. And you obviously hasn't been following along. Consuming dynamic language objects from C#/VB.NET is *extremely* easy (look up the new dynamic type).
1. Fact: MS seems to be moving towards JavaScript and HTML5 as the main development stack for application development instead of.NET 2. Fact: System-level Windows programmers use a systems level programming language (C++) for systems-level development.
Your first "fact" is blatantly wrong. It is a misconception pushed by MS detractors. What they build this contention on is the idea that because MS did *not* mention Silverlight when they demonstrated the Windows 8 tiles, Silverlight had somehow fallen out of grace. If all the technologies *not* mentioned by MS in a random demo must be assumed to be slated for EOL there wouldn't be anything left.
The *real* fact is that Silverlight is very much alive, it is the cornerstone of Phone 7 and will have a very prominent position in Windows 8 as well (more so than in previous versions of Windows). Silverlight and WPF are moving closer (as they should be). The HTML5 emphasis in Windows 8 is a bridge to allow websites to run as seamless Windows 8 tiles. Your favorite sites can offer tiles by simply marking up their website with certain micro-formats. To get an idea look at IE7+ webslices. When you browse to such a site, the tile-able elements will lit up and you can mark them as tiles on Windows 8 desktop. After that, the tiles run as small browsers in which javascript can execute and change content/appearance. But for actuall local apps development, expect to find Silverlight front and center.
And when was Silverlight equated with.NET anyway?.NET > Silverlight. Silverlight is a.NET application, not the entire framework.
Your second "fact" is somewhat correct. But the TFA gives the impression that using Win32 API is somehow difficult or even impossible from.NET. Which is blatantly false. P/Invoke is direct way to make system calls (on any platform). Unlike Java/JNI it directly supports marshalling parameters with no external glue code required whatsoever.
Heh... A JIT does not typically keep all the translations cached... It redoes a LOT of them from time to time. It's a virtualized machine. If it does NOT produce a final native code result that's kept and used directly time and time again, there's SOME interpretation that gets done each time the code is executed.
The context is.NET which indeed does cache all translations for the application domain. It doesn't redo "a LOT" of them as you claim. It compiles an assembly/method only once per process.
.NET does indeed also allow on-installation or ahead-of-time compilation through the ngen.exe tool. It will, as was claimed above, compile to *native* code and store it in the GAC. When such an assembly is used by other.NET code *no* compilation will take place.
Heh... But the drawbacks there are that there's known issues with Patents that until you've sorted out the whole software patent thing, you're better off NOT using Mono.
What a load of FUD. Old FUD at that. You cannot quote a single "known" issue. You only have FSF FUD. MS or anyone else cannot patent an API, only an implementation of a "machine" in the abstract sense. Even if MS is holding a patent on an actual implementation of -say- WPF that doesn't preclude other implementations. If other implementations infringe on the patent, other similar implementations in other languages/platform would as well, and the issue becomes moot.
It's difficult to not get bit by one of them because ECMA's part that Microsoft won't sue over is smallish and you can only really make simple programs with it. Anything else gets you off into a high risk area.
FUD again. Silverlight/DLR is also covered. And ASP.NET MVC is open sourced entirely by MS under a OSI approved open source license with patent grants.
Speaking as a Java programmer, I don't need Linq, because I can choose from Groovy, Scala, Clojure, JRuby, Jython, etc. They are first class citizens in Java and have good IDE support. That's why I don't really care for Java 7 or 8 because I used all the convenient features already (since I learned Groovy).
First class citizens? Then please show us how you consume a JRuby-defined object in Java, calling it's dynamic methods or accessing its fields. Then compare it to how IronRuby or IronPython objects are integrated into.NET (C# or VB.NET). (Hint: seamlessly).
Clearly I need to know more about powershell, since I haven't found anything remotely like that in it. Can you toss me a few links or some examples?
The Invoke-Command (built-in alias icm) takes -Session and/or -Computer parameters. If you invoke a command like icm {ps} -cn host1,host2,host3
* You are simultaneously executing the ps command on several hosts.
* The results are marshalled back to your current console, but a property (hostname) is added to each returned item (remember, pipelines are object-oriented in PS) so that your script can tell the results apart.
* Authentication and authorization and encryption is automatic (no need to exchange SSL keys).
* Using WBEM which is a SOAP protocol which makes it much easier to route through firewalls.
* The {ps} is actually a script block. This block can be arbitrary complex (contain loops, branches, function defs etc). It is *not* just a text string passed to a remote shell.
* The command can also take a script file which is then parsed and sent as a script block.
* If multiple hosts are used, the processing is parallel (simultaneous). Fan-out remoting. The command will wait for all remote commands to complete (successful or failed) before continuing. Results are consolidated in a single result stream. Results are automatically serialized/deserialized from the remote computers retaining structure.
* The script block can define parameters which can be passed like e.g. icm {param($pname) ps $pname} -cn host1,host2 -arg svc*. An elegant way to marshal input object without hassling with quoting and escaping. And remember, these are full-fledged (serialized) objects, not just text strings.
* The Invoke-Command cmdlet also takes a -Job switch. -Job will cause the commands to execute as remote jobs, i.e. they will execute on the remote hosts but they'll be represented by local job objects and can be manipulated transparently.
For simple ssh style remoting (jumping to a remote console) you use Enter-PSSession (built-in alias etsn). Again, this will by default use your current credentials and establish a secured (authenticated and encrypted) connection.
You can step in and out of sessions. A remote "session" retains the environment (variables, state etc) between invocations. If you don't want to "enter" into the session to issue commands, the Invoke-Command (see above) also allows the remote command to be issued from the "outside".
There is plenty more, e.g. implicit remote commands, remote events etc. In general they have been implemented with transparency, i.e. they work seamlessly across machine boundaries because of automatic serialization/deserialization. For instance, PowerShell has a Write-Progress cmdlet which can be used to display a progress indicator for long running scripts. If executed remotely, the status messages are still marshalled back to the console and updates the progress indicator on the console, not on the remote computer.
* You cannot resize it *dynamically*. You can most certainly set the size to something different using the properties. You can also set the window and buffer sizes from script.
* It does copy-on-. Set it to use "quick edit" mode. You can set it on the shortcut as a default
* Which keyboard shortcuts? ** Are you thinking of the PowerTab extension (http://powertab.codeplex.com/). That surely is impressive. ** Yes, the powershell ui can be customized.
* Operations do odd things? ** Check your $OutputEncoding. Default should be ascii encoding
Here here! I didn't know Powershell still uses the crap default terminal!
PowerShell is a "hostable" shell, meaning that it can be integrated into a host (.NET) application and directly share in-memory objects and hook into the host user interface. PowerShell comes with two apps for hosting it: The PowerShell console and the ISE (Integrated scripting environment). What you are referring to as the "crap default terminal" is probably the PowerShell console. I don't know why it is crap, though. If you are thinking lack of SSH, PowerShell has a much more elegant and hassle-free way to remotely execute scripts, commands, functions and even remote jobs and events.
Slashdot Mirror
Cool! Can I use this C# language to create desktop apps that run without modification on Linux, Mac OS X and Windows?
yes: http://www.mono-project.com/Main_Page.
You have a choice between Windows Forms or GTK as the widget toolkit. Both are supported on X11, Win32, and OSX.
Is there a cross platform IDE for this C# language that allows me to develop in the same IDE on Linux as my colleagues do in Windows or OS X?
yes: http://monodevelop.com/
The point is that something developed in the open is often unfairly punished here, as although the betas/nightlies are quite clearly marked "use at your own risk", and only intended to be used by appropriately clued up people, vulnerabilities in them are still disclosed even tho they are generally of no consequence.
Not unfair at all, as bugs found during beta are not assigned CVEs. They never become "official" vulnerabilities. CVEs only track vulnerabilities in released software.
One example would be http://www.phreedom.org/solar/exploits/msasn1-bitstring/ [phreedom.org]
There was a disclosed vulnerability in the microsoft asn.1 library, but the patch for it brought along a fix for another vulnerability in the same library that was not disclosed. This vulnerability was subsequently found by third parties, who produced and released a working exploit forcing microsoft to admit to the vulnerability several months later.
What you have is evidence that a code change Microsoft did also removed another vulnerability. That could very well be a side-effect of simply fixing the first bug by cleaning up the algorithm. It does not demonstrate that Microsoft knew about the bug in the first place.
The exact same thing could happen with any other software. When Mozilla fixes a bug in in a rendering algorithm by re-implementing it, I could also claim that they silently fixed *other bugs* within that algorithm, even if they were not recognized at the point. We wouldn't assume malice on part of Mozilla for that.
Or consider how Microsoft re-implemented TCP/IP for Vista. Does that mean that they silently fixed all bugs which from that point were found in the old stack? Silly.
Firefox reports every vulnerability discovered, even those discovered in alpha and beta versions (which is a normal function of beta testing)...
They report them in the open, but they are *not* considered vulnerabilities of released software and they are not reported as such to NVE or Mitre and they are not assigned CVEs. You cannot find any CVE referring to a beta or alpha version of FF.
By contrast, commercial software is rarely available to the general public at all until a late beta stage, bugs found and fixed during the early development phases will never be disclosed to the public
Yes, well, when it is not available any security bugs found during the testing/security push don't matter, do they? I mean, I expect the vendor to make a security push, reviews and fuzzing during both development and testing. The final product which is released is what should be judged.
Commercial companies, not just browser makers, generally only admit to vulnerabilities which have (or are threatened to be) independently published, because admitting to vulnerabilities is bad for business and not something any for-profit company would do if they have the chance not to.
And you have proof of this. Or is it just speculation. Many vendors have a customer base who rely on the vulnerability disclosures being accurate. That is why the disclosures have to be accurate. A customer looks at the patch and based on which product/part it patches (is the part deployed, is it critical, is it exposed) and the description of the vulnerabilities being addressed (would they pose a risk to the customer) they decide whether to patch their systems or skip it and prioritize stability.
While vendors may have a small interest it keeping the CVE count low, at least some of them have a bigger interest in serving their existing customers with reliable information with which they can make informed decisions. The latter is *much* more important to at least MS than the former.
In other words, it is *not* in MS own interest to sneak in vulnerability fixes without disclosing them. Doing so would put their customers at risk of making uninformed and potentially dangerous decisions. Imagine the outcry if MS sneaked in a fix which were not applied by customers because they decided that the *disclosed* vulnerabilities did not pose a risk.
CVEs - taken over a period of time - actually *is* a good measure of the quality control process of the vendor. Microsofts security focus following the disasters at the beginning of the century is starting to pay off. Mozilla is the new insecure bloat. Well, and Adobe. And Java.
An even better defence against such attacks, is Apple's model... If you can't install/execute anything that's not come from a trusted source, social engineering simply isn't going to work...
To be fair a white-list has been possible on Windows since (at least) Vista. This has been beefed up at little with Windows 7 / 2008R2. Security policy settings allow an administrator to enforce a number of rules, such as path rules, network zone rules, hash rules and certificate rules.
The certificate rule is rather advanced and based on authenticode. Basically an admin can set up rules for specific vendors or all vendors where the code has been signed using a certificate from a trusted set, i.e. through trust of a root cert. For instance you can set up a rule which requires all executables to be signed using a certificate issued by a trusted root (Verisign) and then white-list vendors such as Microsoft, Adobe (if you dare), Apple (if you dare) etc.
The network zone rule is also interesting because it can restrict software based on where you've got it. The zone from where you downloaded the software is stamped into an alternate datastream on downloaded files. The policy can then deny execution of anything coming from the Internet or even the local intranet.
An even better defence against such attacks, is Apple's model...
A whitelist approach certainly has its advantages - securitywise - to a blacklist (reputation) approach. However, in the case of Apple you get the distinct feeling that in also coincides with their strangehold on the revenue stream. With a white-list approach you give up freedom and convenience. In the case of iOS you subject yourself to the whim of Apple. Some don't see a problem with that. Personally, I think it interferes with the computer as a general-purpose device. However, as computers (and phones in particular) are becoming commodities I can certainly see the allure of the white-list.
However what i will say, is that there should be a good selection of such systems, each operated by different gatekeepers. Having a single monoculture is a very bad thing.
Very good point. I have pondered that myself. A system a little like SSL certificates or domain authorities. It is not without problems, though. For one thing, it would kill "free" software on those devices. I don't suspect that an approval (code signature) will be given away for free. After all, the reputation provider takes a risk every time they issue a signature. If they let themselves be fooled their own reputation may be on the line. And then there's the risk of rogue reputation providers just like payment processors. Russia, looking at you.
Since people don't tend to read the article (much less the NSS Lab's purchased findings that were mislabelled as a study)
So did you read the study? Did you come across the following section?
This report was produced as part of NSS Labs’ independent testing information services.
Leading vendors were invited to participate fully at no cost, and NSS Labs received no
vendor funding to produce this report.
Actually, this is a running study, so it also reflects the speed by which the browser vendors update their respective reputation databases. Some 85 new urls were entered on average each day (after being confirmed as malware-serving urls) throughout the quarter. NSS releases these results each quarter.
You have a valid point about the sandbox - but the study doesn't really do security a justice, when comparing the browsers.
Malware is seldom a browser injection issue, but is instead vectored through plug-ins (I'm looking at YOU, Adobe!) which are privileged at a higher-level than the "sandboxed" container application.
No. These days some 85% of infections derive from social engineering. Malware comes in through the user. Vulnerability exploits seems to be a lot less effective these days. Social engineering is precisely what the tested security (reputation) mechanisms are aimed at.
Having said that, yes, Flash is really, really bad. So is Java. And both are rather prolific, regrettably.
I could deliver extended anecdotes about the 0-day flash and pdf exploits that I've witnessed, unfolding right in front of me... Suffice it to say, fully patched systems with browser sandboxes are not immune. :-)
That piques my interest. When was this? AFAIK there has not been a *single* in-the-wild sandbox breach of neither Chrome nor IE (yes, pwn2own demonstrated a combination of 3 techniques which escaped the IE sandbox - but this has not been reported in the wild). Up until some (fast) versions ago, Chrome did not sandbox Flash. IE did that since IE7.
The combination of security and privacy extensions that are developed for Firefox are, still, unmatched. Ghostery, AdBlock+ and BetterPrivacy will together prevent the opportunity to ever render many of the malicious, content delivered exploits. They also serve to screen and scrub the most pernicious of web-threats: covert bugging and monitoring of the browser by a third party.
Whether they are unmatched is a matter of opinion. Firefox requires addons and will block more broadly (which is desirable to some). To me, the fact that FF code quality seems to lack (they have had most vulns reported for the last 5 years going) combined with their nonsensical refusal to implement a sandbox makes it a no-go for me. (I'm, using Chrome, btw).
Citation please? Actually don't bother, because the statement is impossible to support with any amount of evidence.
2008: http://www.favbrowser.com/firefox-browser-with-the-most-disclosed-vulnerabilities/
2009: http://tech.blorge.com/Structure:%20/2009/11/09/firefox-leads-in-browser-vulnerabilities/
2009: http://www.computerworld.com/s/article/9140582/Firefox_flaws_account_for_44_of_all_browser_bugs
You can also query Secunia for vulnerabilities. With the new version number scheme and ultra-fast previous versions retirement (where you are left vulnerable if you don't upgrade immediately), you'll have to grok the numbers somewhat. Basically count the *unique* CVEs affecting all FF versions since -say FF3.5. Do the same for IE8&9. You will not like the result.
Firefox is the only major browser that openly reports vulnerabilities so of course it is going to have the highest publicly countable number.
BS. All the major vendors are obligated to report vulnerabilities through Mitre. All browser vulnerabilities are assigned unique CVEs.
And even if you had an accurate count of known vulnerabilities from the other vendors, known vulnerabilities hardly equates to total vulnerabilities, even less so when every vulnerability is counted as equal to every other one.
If you consider a set of browsers which must be assumes to receive an equal amount of scrutiny (IE,FF,Chrome), if one browser year after year comes out with most vulnerabilities, surely that does say something about code quality.
This report was produced as part of NSS Labs’ independent testing information services.
Leading vendors were invited to participate fully at no cost, and NSS Labs received no
vendor funding to produce this report.
Firefox still does not have a sandbox in place. That right there is a severe problem. Especially as Firefox is *the* browser with most vulnerabilities. The only thing Mozilla has going for Firefox security is that they are really fast to patch once a vulnerability has become known.
Don't run bad code as root, and certainly not as a persistent server. Setuid servers are pretty much a thing of the past anyway.
Eh? Setuid servers are at the centre of sudo and sudoers. In reality sudo is a kludge designed to protect an inadequate and dangerous security mechanism and to mitigate the need for everyone to know the root password. Nevertheless, the stupidity of setuid was brought about because of an initially inadequate security model. A security model where only root could perform certain functions and if anyone else had a legitimate need to perform those functions they had to become root at least temporary. Because only root may perform those tasks.
Look up the KISS rule. Complex security rules that humans can't understand make security worse not better. ACLs result in scanning though lists to match rules which kills performance. Cleaner is better.
KISS is fine. When it is sufficient. When it becomes too simplistic it becomes just stupid. Me-us-world is clearly not sufficient beyond a single user system. Unix file permissions was conceived in the permissive research/education environments of the 1970ies. The problem is that now there are multiple “us”. Proper ACLs are a requirement for government and business certifications these days.
ACLs result in scanning though lists to match rules which kills performance. Cleaner is better.
Ah, but the Windows designers thought of that, you see. That is where the object-oriented handles come into play. In Windows you access objects though handles not syscalls, be it processes, files, directories, registry entries, TCP ports etc. When you open a handle you request a certain access. If you request a given access (and it is granted), the corresponding method of the handle is mapped to the actual function. If you didn’t request a certain access the corresponding method (say, “modify”) is mapped to a “denied” method. When you later invoke operations on the handle, the operation is mapped directly to the method entry. No access check takes place at this point because that was all resolved when the handle was opened/created.
Inheritance of security makes a complex mess more complex and impossible to understand. Look up the KISS rule. You clearly don't know anything about groups or the effects of setgid on directories either.
Inheritance allows admins to achieve sensible security by default, like when they set a web site directory tree to be readable by account under which the web server runs. They allow the web server account read access and sets it to be inheritable. That way the admin of each site can create new directories (under his own account) and the webserver can still serve the files. And yes, inheritance can be broken if the web site admin wants to restrict access to a sub tree.
Not strictly true as root can be separated into capabilities.
Not strictly true? How about just true? Root can not be “separated” into capabilities. The check for uid 0 is hard coded into the system and will allow root to do *anything* without questions asked and often without audit logging. True, Linux has defined capabilities which can be assigned to non-root users. Use them much? Last time I checked my Ubuntu installation not a single utility had been assigned a capability instead of setuid.
So how does the limits on what 'administrator' can do help when there are countless exploits that give system level access?
Strawman. Privilege escalation bugs have been found in every OS. Does that mean that we should just abandon security? Do you have any data (beyond your belief system) that this is more common in non-Unix/Linux systems?
It's possible to change the permissions, capabilities, or chroot a process. You don't seem to know wha
Yeah, good UNIX proven design
Like setuid servers (not!) where even simple bugs allow an attacker direct root access
Like the hopelessly inadequate me-us-world security coarse-grained security which requires proper ACLs to be bolted on top.
Like you cannot set up proper inheritance of security from parent folder, leading admins to design strange processes to wake up and chmod files.
Like the almighty root to rule them all. No separation of duties there. (Windows has proper separation of duties based on privileges. Even admin does not own all privileges, for instance the admin *cannot* write to or clear the security log).
Like the UNIX idea of a "token" which are just UIDs hard-wired to user accounts. (Windows has *real* process tokens which can be manipulated per process, e.g. stripping certain privileges from a process even if it runs under an admin account).
Windows security design is not perfect, but it is a god deal better designed and more capable than the "UNIX proven design". Why do you think SELinux was developed by the NSA? Because Linux with its "proven design" was woefully inadequate for government work - a task for which Windows is certified but only few Linuxes - those with SELinux).
We keep hearing about this "superior" Unix security design. But it is always referred to in the abstract with no details. Maybe it is some magical fairy or Apple dust?
Yes, a good admin can lock down a Linux with apparmor or SELinux pretty tight. Both apparmor and SELinus are solutions which compensates for the initial inadequate design.
I can't really see what sort of functionality you need out of a tcp stack that wasn't already there. Anything else can be bolted on top.
From Windows Internals, Fifth Edition (Mark E. Russinovich; David A. Solomon; Alex Ionescu):
The Next Generation TCP/IP Stack offers several advanced features to improve network performance, some of which are outlined in the following list:
Those of us who are old enough remember the "portions copyright the regents of the University of California Berkeley" (or words to that effect) that used to be part of the Windows legal declarations from 95 onward. It has been considered common knowledge that their pre-Vista TCP/IP stack was taken from BSD, as was their FTP executable
The "common knowledge" here is an euphemism for myth. Back in Windows NT 3.1 (!) MS licensed a TCP/IP stack from Spider. That *may* have been based partially or entirely on the BSD stack of the time. However, as of Windows NT 3.5 and Windows 95 that stack had been replaced by Microsofts own stack. Some of the utilities (ftp client, ping?) were still the original BSD utilities, or based on them. The network stack has not been BSD since Windows NT 3.1.
If you're going to claim otherwise, you should offer some citations please.
here you go: https://www.kuro5hin.org/?op=displaystory;sid=2001/6/19/05641/7357
Nope, the "from the ground up" rewrite was for Vista, although they had previously partially rewritten the stack for Win 2K and for XP I believe.
Incorrect, it had been previously rewritten for Windows NT 3.5. See above.
But if you were paying attention back during the interminable Vista beta process, you would've remembered the noise about those old TCP/IP vulnerabilities, solved long ago, that Microsoft re-introduced with their new stack.
Citation? or should I write
If you're going to claim otherwise, you should offer some citations please"
Do I understand their presentation correctly? Users in said Enterprise have admin privileges?
No. The point is that *any* device which gets access to a network with OS X server can:
1) Wait to be contacted by OS X server. The server will stupidly identify itself with network-wide credentials (can be used for other hosts)
2) Device under attacker'c control turns around and starts contacting *other* machines using the credentials it has just learned from the server.
3) Other OSX machines will stupidly answer the request and will previde their *own* credentials since you are "obviously" a trusted server.
4) Harvest the acquired credentials
5) Profit.
The "any device" may be a compromised client or a prepared device (notebook?) hooked on to the network through physical or WiFi breach. How is not the point of TFA, it is the potential consequences. A single client/device under an attackers control allows him to harvest the password set.
Indeed this is a braindead design flaw.
So long as there is an option for disabling js completely on read, and sand boxing it fully when it is turned on ( something browsers have been doing for years) moving to js and HTML would not make office any less secure, and possibly more secure as rendering js and HTML is a well understood problem.
I believe that Office is already (2010) sandboxing documents. IIRC documents "tainted" with an Internet origin will open in a sandboxed (low-integrity) process.
And Mac OS X explicitly warns you if you are about to open an application downloaded from the Internet. This means that getting someone to run your code requires tricking them (through social engineering) into knowingly launching an application that they've never launched before, as opposed to tricking them into running your code by making it look like a JPEG file of Lindsay Lohan naked or whatever. Maybe Windows 7 does the same thing (I'm not sure), but that was at least historically a big problem on Windows.
In Windows, files downloaded from the internet has the origin written in an alternate datastream. If you execute such a file you get a warning (like in OS X), but then even if you choose to run the executable, it will run with low integrity. Low integrity is part of UAC and sandboxes the process so that it by default has only read access as the current user. Write access (safe a few cache locations) is completely blocked, safe a few safe cache locations. This is a major obstacle for anyone wanting to use a trojan to install malware. He cannot even infect the local user, bar som sandbox escape vulnerability or some more clever social engineering.
Try a contest where the first person to break *any* system gets $10.000 or $15.000. Then you have pwn2own. And then you'll see that the attackers attack the system they believe most vulnerable first. Or they risk someone else does it. What you'd rather have, a MB pro + $5000 or a HP/Dell + $15.000?
The two problems with .NET is that it promised a lot of things that are either false or pointless.
1) Strawman. Microsoft never promised cross-platform. .NET was developed when Sun refused to let Java become a viable option for writing native apps. Java always insisted on "virtualizing" the OS - even rendering each pixel of screen widgets. MS rightfully felt that this was offering a sub-par user experience and first tried to worm in the ability to use native widgets - and when that failed they created .NET. Which has P/Invoke which offers a much better integration to the underlying OS than anything Java.
2) False; .NET actually *is* language independant. Unlike Java .NET was designed with this in mind from the start, hence the CLR was always "bigger" (had features not exposed in C# or VB) than any one of the languages. And you obviously hasn't been following along. Consuming dynamic language objects from C#/VB.NET is *extremely* easy (look up the new dynamic type).
1. Fact: MS seems to be moving towards JavaScript and HTML5 as the main development stack for application development instead of .NET
2. Fact: System-level Windows programmers use a systems level programming language (C++) for systems-level development.
Your first "fact" is blatantly wrong. It is a misconception pushed by MS detractors. What they build this contention on is the idea that because MS did *not* mention Silverlight when they demonstrated the Windows 8 tiles, Silverlight had somehow fallen out of grace. If all the technologies *not* mentioned by MS in a random demo must be assumed to be slated for EOL there wouldn't be anything left.
The *real* fact is that Silverlight is very much alive, it is the cornerstone of Phone 7 and will have a very prominent position in Windows 8 as well (more so than in previous versions of Windows). Silverlight and WPF are moving closer (as they should be). The HTML5 emphasis in Windows 8 is a bridge to allow websites to run as seamless Windows 8 tiles. Your favorite sites can offer tiles by simply marking up their website with certain micro-formats. To get an idea look at IE7+ webslices. When you browse to such a site, the tile-able elements will lit up and you can mark them as tiles on Windows 8 desktop. After that, the tiles run as small browsers in which javascript can execute and change content/appearance. But for actuall local apps development, expect to find Silverlight front and center.
And when was Silverlight equated with .NET anyway? .NET > Silverlight. Silverlight is a .NET application, not the entire framework.
Your second "fact" is somewhat correct. But the TFA gives the impression that using Win32 API is somehow difficult or even impossible from .NET. Which is blatantly false. P/Invoke is direct way to make system calls (on any platform). Unlike Java/JNI it directly supports marshalling parameters with no external glue code required whatsoever.
Heh... A JIT does not typically keep all the translations cached... It redoes a LOT of them from time to time. It's a virtualized machine. If it does NOT produce a final native code result that's kept and used directly time and time again, there's SOME interpretation that gets done each time the code is executed.
The context is .NET which indeed does cache all translations for the application domain. It doesn't redo "a LOT" of them as you claim. It compiles an assembly/method only once per process.
.NET does indeed also allow on-installation or ahead-of-time compilation through the ngen.exe tool. It will, as was claimed above, compile to *native* code and store it in the GAC. When such an assembly is used by other .NET code *no* compilation will take place.
Heh... But the drawbacks there are that there's known issues with Patents that until you've sorted out the whole software patent thing, you're better off NOT using Mono.
What a load of FUD. Old FUD at that. You cannot quote a single "known" issue. You only have FSF FUD. MS or anyone else cannot patent an API, only an implementation of a "machine" in the abstract sense. Even if MS is holding a patent on an actual implementation of -say- WPF that doesn't preclude other implementations. If other implementations infringe on the patent, other similar implementations in other languages/platform would as well, and the issue becomes moot.
It's difficult to not get bit by one of them because ECMA's part that Microsoft won't sue over is smallish and you can only really make simple programs with it. Anything else gets you off into a high risk area.
FUD again. Silverlight/DLR is also covered. And ASP.NET MVC is open sourced entirely by MS under a OSI approved open source license with patent grants.
Speaking as a Java programmer, I don't need Linq, because I can choose from Groovy, Scala, Clojure, JRuby, Jython, etc. They are first class citizens in Java and have good IDE support. That's why I don't really care for Java 7 or 8 because I used all the convenient features already (since I learned Groovy).
First class citizens? Then please show us how you consume a JRuby-defined object in Java, calling it's dynamic methods or accessing its fields. Then compare it to how IronRuby or IronPython objects are integrated into .NET (C# or VB.NET). (Hint: seamlessly).
Clearly I need to know more about powershell, since I haven't found anything remotely like that in it. Can you toss me a few links or some examples?
The Invoke-Command (built-in alias icm) takes -Session and/or -Computer parameters. If you invoke a command like
icm {ps} -cn host1,host2,host3
* You are simultaneously executing the ps command on several hosts.
* The results are marshalled back to your current console, but a property (hostname) is added to each returned item (remember, pipelines are object-oriented in PS) so that your script can tell the results apart.
* Authentication and authorization and encryption is automatic (no need to exchange SSL keys).
* Using WBEM which is a SOAP protocol which makes it much easier to route through firewalls.
* The {ps} is actually a script block. This block can be arbitrary complex (contain loops, branches, function defs etc). It is *not* just a text string passed to a remote shell.
* The command can also take a script file which is then parsed and sent as a script block.
* If multiple hosts are used, the processing is parallel (simultaneous). Fan-out remoting. The command will wait for all remote commands to complete (successful or failed) before continuing. Results are consolidated in a single result stream. Results are automatically serialized/deserialized from the remote computers retaining structure.
* The script block can define parameters which can be passed like e.g. icm {param($pname) ps $pname} -cn host1,host2 -arg svc*. An elegant way to marshal input object without hassling with quoting and escaping. And remember, these are full-fledged (serialized) objects, not just text strings.
* The Invoke-Command cmdlet also takes a -Job switch. -Job will cause the commands to execute as remote jobs, i.e. they will execute on the remote hosts but they'll be represented by local job objects and can be manipulated transparently.
For simple ssh style remoting (jumping to a remote console) you use Enter-PSSession (built-in alias etsn). Again, this will by default use your current credentials and establish a secured (authenticated and encrypted) connection.
You can step in and out of sessions. A remote "session" retains the environment (variables, state etc) between invocations. If you don't want to "enter" into the session to issue commands, the Invoke-Command (see above) also allows the remote command to be issued from the "outside".
There is plenty more, e.g. implicit remote commands, remote events etc. In general they have been implemented with transparency, i.e. they work seamlessly across machine boundaries because of automatic serialization/deserialization. For instance, PowerShell has a Write-Progress cmdlet which can be used to display a progress indicator for long running scripts. If executed remotely, the status messages are still marshalled back to the console and updates the progress indicator on the console, not on the remote computer.
* You cannot resize it *dynamically*. You can most certainly set the size to something different using the properties. You can also set the window and buffer sizes from script.
* It does copy-on-. Set it to use "quick edit" mode. You can set it on the shortcut as a default
* Which keyboard shortcuts?
** Are you thinking of the PowerTab extension (http://powertab.codeplex.com/). That surely is impressive.
** Yes, the powershell ui can be customized.
* Operations do odd things?
** Check your $OutputEncoding. Default should be ascii encoding
Here here!
I didn't know Powershell still uses the crap default terminal!
PowerShell is a "hostable" shell, meaning that it can be integrated into a host (.NET) application and directly share in-memory objects and hook into the host user interface. PowerShell comes with two apps for hosting it: The PowerShell console and the ISE (Integrated scripting environment). What you are referring to as the "crap default terminal" is probably the PowerShell console. I don't know why it is crap, though. If you are thinking lack of SSH, PowerShell has a much more elegant and hassle-free way to remotely execute scripts, commands, functions and even remote jobs and events.