Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:I want (Score 4, Interesting) 85

by benjymouse (#49048071) Attached to: Microsoft Releases Windows 10 Preview For Phones

Not a troll but a genuine question - what's stunted about ASP.NET MVC?

ASP.NET MVC along with the other "web MVC" have really little to do with the real MVC as in the original smalltalk MVC described by Trygve Reenskaugs MVC. Web MVCs are bastardizations of the original concept, often only riding the name for recognition. I blame Struts and RoR for starting this trend.

I believe grand parent was referring to the original MVC which was a way to design interactive, event-driven GUIs. The original MVC was a recursive concept: The view could itself be a "tool" that in turn followed the MVC pattern. See http://heim.ifi.uio.no/~trygve...

As far as "web MVCs" goes, ASP.NET MVC is a really good one. But real MVC it is not. But that's a lost cause. An entire generation of developers have grown up believing that RoR and Struts were examples of MVC. In actuality, the designers og Struts and RoR grossly misunderstood the concept.

Comment: Re:Subjects Are Stupid (Score 1) 93

by benjymouse (#48995613) Attached to: LEGO Contraption Allows Scientists To Safely Handle Insects

I'll be "that other guy" and point out that Lego is not an acronym.

Uhm. From WhatIs.com:

An acronym (pronounced AK-ruh-nihm, from Greek acro- in the sense of extreme or tip and onyma or name) is an abbreviation of several words in such a way that the abbreviation itself forms a pronounceable word. ...

Abbreviations that use the first letter of each word in a phrase are sometimes referred to as initialisms.

LEGO is an abbreviation (though not an initialism) of Leg godt, danish for "play well" - or perhaps more like "have fun (playing)"

So it appears that it is an acronym

Comment: Re:Not *that* unused (Score 1) 471

by benjymouse (#48980381) Attached to: Systemd Getting UEFI Boot Loader

Windows 64 bit has an absolute kernel-driver signing requirement. Windows 32 bit has for compatibility reasons a more "soft" requirement - that's where you'll get the warning box instead. Reason: Windows is still compatible with drivers from the XP/2000 era and will still load those. At that time nobody had considered driver signing, and the vendor may now be defunct. An absolute requirement would render devices unusable. The signing requirement was in force when 64 bit was introduced, and MS reckons that all drivers for 64 bit must have been signed, thus the signing requirement is non-negotiable on x64.

You *can* load non-signed drivers by attaching a kernel mode debugger. This is to facilitate development of drivers without a long signing roundtrip.

Comment: Re:How many... (Score 2) 253

Oh, that promise is legally binding? I don't think so. And CEOs change.

Yes, it is binding. Legal estoppel is the term. It is used when you act in good faith on a promise. It is in fact one of the strongest contract types you can imagine, because it is considered a one-sided contract that you do not even have to accept (like you do with e.g. license terms). If you can show that you acted on the promise, a patent case against you will be dismissed.

Comment: Re:Not *that* unused (Score 1) 471

by benjymouse (#48977315) Attached to: Systemd Getting UEFI Boot Loader

There is a big difference between mitigation and prevention. Secure boot is a prevention mechanism: It prevents the system from booting if the boot chain has been tampered with. You can boot from external media such as an USB key and salvage data, but the system will not boot by itself.

What you are suggesting is a mitigation mechanism. As I wrote above, code running in a security context cannot protect effectively against code running in the same security context. It can only try to *mitigate* such attacks, but mitigation are speed bumps compared to prevention, which are road blocks

Windows certainly has it's share of mitigation mechanisms. First there are all the anti-exploit mitigation mechanisms which are designed to thwart an exploit from getting foothold, even when a vulnerability exists in 3rd party code. These are stack overflow/underflow prevention, DEP/ASLR, heap encryption/checksumming, safe structured exception handling (SafeSEH) etc etc.

Then there are the built-in running mechanisms such as ELAM, patchguard etc. Patchguard will checksum central kernel tables, and if malware tries to gain foothold in the (running) system by patching into e.g. the page table, patchguard will react to the checksum discrepancy and halt the system.

Secure Boot prevents a compromised system from ever starting. Your suggested mechanism is already there - Windows will *try* to prevent unauthorized patching. But that is mitigation and far less effective than prevention.

Comment: Re:Not *that* unused (Score 1) 471

by benjymouse (#48977287) Attached to: Systemd Getting UEFI Boot Loader

To be loaded as a driver, the driver must be signed.

Correct me if I'm wrong but to be loaded as a driver, the driver must simply start a UAC prompt and then let the user click yes, and then yes again to the unsigned driver dialogue.

If you rely on a user not clicking yes then you have a very big gaping security hole.

Consider yourself corrected. UAC has nothing to do with drivers. Kernel mode drivers under Windows *must* be signed by a recognized authority. If a driver is tampered with, the kernel will refuse to load it. If a driver is unsigned, the kernel will refuse to load it. On x64 systems, the user can *not* opt to override this warning.

UAC prompts has to do with integrity levels - which is a way to divide processes, files, registry keys etc into "trust zones" and isolate processes running with lower trust (lower integrity level) from accessing resources having higher trust (higher integrity level). Even when your account has admin rights, the admin rights are stripped from your token at login, i.e. you are running as a standard user without any special privileges. Windows saves the "full" token, but it is not active. When you start a process based on an image that declares in its manifest that it must run as admin, Windows will issue the UAC prompt on a separate secured desktop. If you accept the elevation (that your admin privileges can be used for the process), Windows starts the new process with the "full" token - and with high integrity level.

Comment: Re:Not *that* unused (Score 3, Informative) 471

by benjymouse (#48970811) Attached to: Systemd Getting UEFI Boot Loader

In Windows, it's not unheard of that a piece of malware with sufficient access interjects itself where the next boot will be picked up before the OS has a chance to set up it's own protection. Of course my complaint is that this vector would have easily been sidestepped without a huge firmware mess. If the OS set up access to that area as very very very very special, requiring signed code within the OS to modify that section of the platform, then the problem would have been solved. .

Sorry, but no. If you knew anything about threat modelling and OS design, you would know that code running at a trust level cannot protect against other code running with the same trust. The x86 architecture does have 4 levels, but for a number of reasons (mostly portability) practically no OSes use more than 2 levels (rings): protected/kernel and user mode.

What you are proposing is using a 3rd ring - something more privileged than kernel mode. This would constitute a major architectural redesign and would trash portability/compatibility with other architectures.

The fact is that UEFI Secure Boot is a very effective mechanism for blocking boot sector infections. As Windows has grown ever more resilient against permanent infections (app/driver signing, checksum tables, strong named assembly cache etc) malware authors were forced into infecting at an earlier stage of the boot process, if they wanted to take up permanent residence.

The OS kernel mode MUST have the capability to write all sectors of the disk. It can effectively block usermode apps from writing such sectors, but if kernel mode driver contains a vuln, rogue code can bypass any security mechanisms enforced by the kernel. It can just jump to the address efter the security check or control the IO itself.

Bootkits exists for Wndows. It was a real threat. A few unscrupolous individuals (lookng at you Garett) chose to instigate a FUD campaign, deliberately misrepresenting facts and knowlingly failing to correct misunderstandings when they advanced their case.

And you are still part of that.

Comment: Attack surface (Score 1) 88

How about 'no'.


Consider the situation where an attacker has actually compromised a server key - either it was leaked, brute forces, a vulnerability exploited. It happens and big parts of the certificate system such as revocation lists, OCSP, validity periods etc are concerned with this. Or consider the situation where a vulnerability allows the attacker to *fake* the fact that he has the private key.

Many systems are set up to warn or outright block if they are not able to check revocation for a certain time period. Seems to me, that with this extension an attacker can use the time from when the key is actually compromised until the breach is discovered/reported and gain permanent foothold instead of a temporary one.

This capability seems too dangerous to even have in the protocol - even if one can argue that it is protected. It broadens the attack surface in a significant way.

Of course, all security is a balance between risks, consequences and cost. Maybe, if this capability significantly lowers some other risk, it could outweigh the risk incurred by the increased attack surface. But color me skeptical.

Comment: Re:not the point (Score 1) 375

by benjymouse (#48930397) Attached to: Why Screen Lockers On X11 Cannot Be Secure

You download a program that appears legit (and may be mostly legit, or be a hacked version of a legit program), and are running it.

But why would I do that?

Ok, try this: You browse the Internet using Firefox. Lots of vulnerabilities discovered each month, 4 remote code executions already in 2015. An attacker has infected an add or a legitimate or fringe site you visit. Attack code executes and the attacker now runs his code in your Firefox. The malicious code hooks into X. The code can intercept the lock screen, but it can *also* monitor each and every keystroke entered into ANY other window - including terminal windows - without you noticing it. Lock the screen and unlock it and your password is compromised. Run a sudo in a terminal window and you are pwned!

How's that?

Comment: Re:not the point (Score 2) 375

by benjymouse (#48930387) Attached to: Why Screen Lockers On X11 Cannot Be Secure

Yes, that is exactly my point.

Nice try. But no, you are BSing.

Scoth: "Windows has had the ctrl-alt-del to log in/unlock since literally the first version of Windows NT, 3.1, in 1993. "

You: "In 1993, Windows didn't have an NT kernel."

AC: "In 1993, Windows NT 3.1 was released. Not to say that the non-NT product line ended at the same time."
(AC factually correct here: Windows NT 3.1 was released in July 1993)

operaghost: "Windows NT 3.1 didn't have an NT kernel? Color me confused. No, scratch that-- color you wrong."

You: "Go to a typical computer store in 1993, ask for Windows, and they wouldn't give you an NT kernel."
(now you try to deflect; why bring in the "typical computer store"? the issue was *Windows NT*)

So, your claim was that Windows NT didn't have an NT kernel. The TFA was about Windows NT, and Windows NT certainly HAD the NT kernel, it certainly HAD the "attention sequence" Ctrl-Alt-Del, and it certainly WAS released and available.

And you are dishonest.

Comment: Re:If it's accessing your X server, it's elevated (Score 3, Informative) 375

by benjymouse (#48930197) Attached to: Why Screen Lockers On X11 Cannot Be Secure

I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?

Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device.

Except in Windows. Since Vista user interface privilege isolation prevents unauthorized processes from grabbing keyboard/mouse events or sending messages to windows owned by another process, even if that process is running as the same user. To be allowed to grab keyboard/mouse, the process must have declared that intent in the manifest *and* it must have been launched from an installed location (program files or windows system). Furthermore, such hooking/messaging is also masked out at the intrinsic level by UAC - specifically by integrity levels. A lower integrity process is simply not allowed - manifest or not - to send messages or install keyboard/mouse hooks at a higher integrity level process.

X is especially bad in this regard, as it does not even protect against shatter attacks and eavesdropping on windows from *another users* processes. If you elevate to root - e.g. sudo from a terminal window - any other process can *still* eavesdrop on keyboard events.

Comment: Re:not great, but probably not very important eith (Score 1) 105

by benjymouse (#48786493) Attached to: Sloppy File Permissions Make Red Star OS Vulnerable

Some alternatives sound nice but fail horrificly when the come in contact with people, especially the ones that let any people within a group grant access to others with zero oversight.

An access control system where everyone (with access?) can grant access to others sounds bad. However, I don't think that's the only alternative to me-us-everyone rwx. In fact, I don't know that such a system that exists at all. You usually needs to be the owner of a resource (or in the "owners" group) to grant privileges in a DAC system. Some systems also allows owners to grant specific rights on the security attributes to non-owners - i.e. the right to grant access.

Within a short period of time with such a "everyone can grant or deny access" scheme you end up with almost everything wide open

How about a system where only owners or designated security administrators can grant/deny access? The issue here was that a developer *wanted* access to a file from a non-owner and non-group member account. Lacking finer grained ACLs, that leaves only "everyone".

It sounds like you believe that discretionary access control (DAC) is the alternative to Unix filesystem permissions. It's not. Unix filesystem permissions is itself a DAC system, albeit a very limited one. DAC only means that the owner of a resource (or a designated security administrator of a resource) can grant access to others. Because the creator of a file is often considered the owner, creators can often grant access to whom they choose.

However, if a user has been granted "read" access to a resource he can usually not grant it to someone else, unless he is the owner. Do you know of a system where, by default, you can grant the same permissions that you have been granted?

Comment: Re:not great, but probably not very important eith (Score 2, Informative) 105

by benjymouse (#48786099) Attached to: Sloppy File Permissions Make Red Star OS Vulnerable

This kind of exploit, a local privilege escalation exploit, used to be very significant, but is significant in a declining number of cases, as old-style Unix multiuser systems are a smaller and smaller proportion of systems.

An attacker who has exploited a Firefox vulnerability (there are still many found and patched each month) is running as a *local user* on your machine. Trying to explain these types of vulnerabilities away is disingenuous, if not downright complacent.

Unix/Linuxs permission system is 70-era bit-saving stupid. There is no other way to put it.

While this is clearly a mistake by someone packaging the distro, they were certainly not helped by a system where you cannot adequately express permissions. ACLs are available, but they are still kludges and they fell like a bolt-on with many tools still not recognizing them.

When a developer meets the limit of what can be expressed with a single-group me-us-everybody, he will often look for the path of least resistance. Unfortunately that is often relaxing permissions along the coarse-grained me-us-everyone, often ending up with everyone as in this case.

Comment: Re:CryptoWall (Score 1) 463

by benjymouse (#48733661) Attached to: Writer: How My Mom Got Hacked

Incremental is the worst system for restoring. Needing the last full and *all* backups since the last full. Differential is better in that you need the last full and *one* differential. What I think you really mean is versioned backups (not over-written). You can restore from Tuesday's backup (whether full, differential, or incremental is irrelevant), and Tuesday's won't be wiped when Wednesday's is written.

Windows Image backup does *reverse* incremental: An image of the disk is stored as a vhd (virtual hard drive) along with reverse increments so that previous versions can be created. You can attach the vhd and use the "previous versions" feature to go back in time.

Most public domain software is free, at least at first glance.