Haven't been paying attention lately have ya?
Last Black Tuesday fucked up a lot of users of New modern great Windows systems
Less than 0.01% of Windows users. That may be "a lot of users" in absolute terms - but it is certainly not the big failure you (and Infoworld - the tabloid of tech) make it out to be.
Did MS do a proper jon when testing the updates? no. Did they fail massively? no.
Wow, Ubuntu is behind the times.
Fedora can patch and dynamically replace the running kernel without a reboot.
BS. Fedora uses RPM, which is even worse at ensuring that patches become effective.
You are deluding yourself and confusing the fact that you are not instructed to reboot with reboot is not needed. Your complacency means that you processes lingers on in their vulnerable state. Fedora does not use ksplice (Oracle owns that now) and ksplice does depend on the patches being specifically prepared, anyway.
Not all patches require system reboot (same as on Windows). But patches that affect e.g. running network daemons do require a restart to become effective. I hope you are not responsible for administering production systems!
Ubuntu is just one distro of linux, if it is not doing what you want then try the others.
Oh - the universal answer: You are using the wrong distro. Love it. Deflect, avoid, goalposts shifting.
However, in this case (talking about Munich, remember?) they were using Ubuntu as base for Limux.
I still regularly get "need to upgrade reboots" on my Windows machine. It's atleast once a month and always seems to pop up when I'm playing a game of LoL or CS:Go.
Yes, I use my Windows as a Wintendo. Got a problem with that?
And I suppose that Linux is better?
Just this past month I can count several Linux vulnerabilities, the patch for which requires a reboot:
http://www.ubuntu.com/usn/usn-...
After a standard system update you need to reboot your computer to make
all the necessary changes.
The same goes for all of these:
http://www.ubuntu.com/usn/usn-..., http://www.ubuntu.com/usn/usn-..., http://www.ubuntu.com/usn/usn-..., http://www.ubuntu.com/usn/usn-..., http://www.ubuntu.com/usn/usn-...
For this one you have to restart your Unity session:
http://www.ubuntu.com/usn/usn-...
The security notices also includes a number of patches to library files. Under Linux you can replace (patch) a file even if it is loaded in a current process. However, the patches file will not take effect until said process has been restarted.
As far as I know, under Linux there is no automated process for this. Linux will not be able to patch an open LibreOffice Writer application if one of the libraries it uses are being patched. Writer will happily continue running unpatched.
Worse, you will not get a warning, and the running processes may have already loaded some libraries before the patch, and load a version of a library that is incompatible with the running process *after* the patch, simply because the OS/processes are not aware of patches. This leads to application crashes. I regularly experience crashes when I use LO on Ubuntu. Granted, I have Ubuntu installed as a VM and use it rarely, but that also means that there's typically *a lot* of patches waiting for me when I spin up the VM. Linux seems to handle patching libraries poorly and I am not aware of any system mechanism that tries to mitigate this problem.
Under Windows you have the Restart Manager. When a process load a DLL, it also locks the DLL file because it may just discard the memory where it is loaded, expecting to be able to load the exact same image later. Applications (such as Office) registers with the Restart Manager. If the Windows Updater needs to replace a locked DLL file, it looks to see if the processes that locks the DLL are all registered with the RM. If so, it can ask the registered application for their "state", restart the processes and inject the state into the processes when they come back up and registers with the RM. The RM also watches the locked files, and if the last lock that prevents a patch set (multiple files that should be replaced as part of an atomic transaction) is being released, the RM can kick of the file replace operation. This latter part is the reason why sometimes the "need to restart the system" badge disappears without a system restart.
The bottom line: Linux needs restarts/reboots just as Windows does. Sometimes you are deceived to believe that it has fewer restarts because Linux cannot by itself figure out that you *do* need to restart a process or the system. But that's actually worse because it leads to crashes.
How does getting onto the VPN equate to accessing the secret stuff? Isn't there another layer of security?
The Heartbleed bug is an extremely serious information disclosure bug.
Via a simple attack the attackers can read the memory of the VPN appliance which holds the latest SSL keys, passwords, usernames, you name it. The attackers could potentially also have been able to read session identifiers and thus potentially bypass 2-factor auth even if it was in place.
Heartbleed will go over in the history as the most expensive bug of all times. It already is, and we have not seen the last of the consequences.
MSFT is relocating regional headquarters and Munich is a front runner. Lots of potential tax revenue, both directly from MSFT and indirectly from the employees and spin off economic activity.
Selection of Munich would undoubtedly be contingent on the city migrating back. I dont believe any outright bribing was involved or required.
Two problems with your conspiracy theory:
1) The decision to move the HQ was made almost a year ago. Whether or not Munich converts back will not change the plans.
2) The HQ is already in the Munich area. The new HQ will be located apx 15 kilometers to the south of the current one.
Nice try, though.
All fastboot does is skip a few bios checks (eg: fast memory scan instead of full). It will not effect anything else, unless you have a hardware fault which can be detected at BIOS post.
Wrong. Fastboot hibernates the kernel but not the userland processes. It depends on drivers being capable of quickly re-initializing hw devices, but what it does is it brings up the kernel from a hibernated image and skips most of the usual hardware detection and device initialization.
Rule number 1 = Dont use system restore
Rule number 2 = Dont use system restore
Rule number 3 = Google "Stop 0x0000000e" error code on your BSOD.
Rule number 4 = Remember the last thing you did before the BSOD started happening, reverse the process. Job fixed.
Really, really stupid advice. System restore has N previous versions of your driver setup. You can reliably go back in time for the operating system but retain any changes to user files. It is stupid to NOT use system restore. Whenever you install a new driver, the system *will* retain the old files, registry settings etc as shadow copies. It is a well-tested and stable way to go back in time with your os.
"If you do not have media, you should use the power button to restart your computer during the startup process three times. This should start the Windows Recovery Environment. "
Oh yeah, THAT's gotta be good for the hardware. Definite improvement over F8. Thanks Microsoft...
It is actually quite clever: If the system barks 3 times in a row when trying to start, the operating system *should* infer that something is preventing an orderly startup. In that case, dropping into the recovery console is a perfectly good choice.
NTFS has volume shadow copy on by default for the system drive. It records changes to the *system* (Windows/** and Program Files/**) and lets you roll back those changes without rolling back any user/data files.
So even if you f***** up so royally as to make the system unbootable (e.g. a bad disk driver), the system will boot into the recovery console with a minimal number of known "basic" drivers.
Java was supposed to be sandboxed entirely with zero chance of malware getting to anything other than it's own litter tray. Look how that turned out when it was seen as all too hard and compromises were made.
The big problem with Java is that it requires quite a bit of C "glue" code to interface with the underlying operating system. The glue code necessary is often quite complex too, since it has to contend with issues such as the VM rearranging objects (thus glue need to "pin" the objects), garbage collection using a mark-and-sweep (thus the glue code need to make sure objects do not "dissapear" during the call), strange memory layout, multithreading/cpu cache issues etc, etc.
So while from the Java developer things may look simple, copious amount of complex glue code is need with all the traditional opportunities for security bugs.
There are probably more explanations than how the language runtime integrates with the OS, but the comparable
Then there's the opposite that was born stupid, things like Active-X from MS that were such a stupid idea that a librarian (not a programmer) was telling me how stupid it was before launch.
ActiveX controls on the web was a stupid idea. Faced with the threat of Java applets, Microsoft decided to take a sound (and efficient) binary standard from the OS and put it on the web. The big problem with ActiveX is that from the OS perspective (at least until Windows 7) it is but binary code executing under the user account.
Imagine a system where you do not have sufficient control over what a process can do (because it is binary code executing directly against the OS), so instead you try to limit who can use what binary code - and under which circumstances. But once the code executes it acts as part of the host process. That actually works until some sneaks in malicious binary code, or - more likely - someone finds a memory corruption bug or finds a way to use the binary code in ways not intended by the developer.
That is putting a lot of trust in 3rd party developers, trusting that they do not have malicious intent and that they are actually competent and that proper quality assurance processes are in place. That turned out to be a stupid thing to trust (contrary to popular belief there has been precious few vulnerabilities in the ActiveX implementation itself - it was always the ActiveX controls -mostly 3rd party - that had vulnerabilities).
However, the idea behind whitelisting ActiveX controls was not new. It had been tried before (albeit not on the 'net), with similar results in terms of vulnerabilities, exploits and system compromises. To this day SUID/setuid is the most stupid intentional security weakness in the *nix security model, simply because - like with ActiveX - the permission structure is otherwise not capable of meeting simple, legitimate requirements.
Then things like allowing execution of arbitrary code in images, another case of MS fucking up in a truly astonishing way
I believe you may be confusing something here. When there is a vulnerability where a jpeg can "execute arbitrary code" it is *not* intentional. It is usually down to a memory corruption bug (such as buffer overflow), i.e. it is *unintentional*. I don't believe MS has made any image format with intentional capability to execute arbitrary code. If you have information to the contrary, then please cite source.
If you are insinuating that it is only MS who can make mistakes in image processing code, you should tread carefully. Compared to the typical open source libraries (libxml, libtiff, libpng et al) MS has had precious *few* vulnerabilities.
The answer as always is to learn from the lessons of the past instead of throwing together a pile of bits that look software shaped and rushing it out the door.
Yes. But if you want to learn the right lessons you must be careful to perform an unbiased analysis. Otherwise your results will have absolutely zero value towards avoiding similar situations in the future. Your petty attempts at laying this at the door of MS is an example of this. If - in your mind - the problem is simply MS, then you are overlooking the real problems. Ask yourself this: Why is it that it is only MS who has not had a *major* bug in their SSL implementation? (hint: MS SDL outlaws the use of the exact C library functions that were behind Heartbleed, so MS actually has a process in place where they analyze previous vulns and improves the guidelines for future development so that they can avoid *similar* mistakes).
Updates Win 8.1 x64 all patches. No problems.
On the other hand, Apple, Debian and Redhat manage to release timely security patches that don't cause crashing en-masse.
Perspective, please. This seems to be a *very* limited problem and an (as usual) over-zealous Woody Leonhard trying to stir up a controversy.
Infoworld *is* the fox news of tech.
TFA - especially the headline - is grossly misleading click-bait.
The story behind the latest numbers are that Microsoft has taken a write-down on investment in development of the *Surface Mini*. They scrapped that device only days before launch. When you do that, you have to write off all sunk cost on design and development of that product line.
Thus, those accounting numbers say *nothing* about how Surface Pro 3 - or indeed how the Surface line in general is performing in the market. For all we know demand is good but not excellent.
Tablet sales are tanking and PC sales are climbing again. If customers start to view tablets as "not for real work" Surface Pro 3 could be *the* device which is a perfect combination (compromise?) of PC and tablet.
For all the ridicule, Windows 8 does in fact deliver on being both a tablet as well as a PC operating system. The problem was never the tablet part nor the PC part - the main problem (especially with 8.0) was the rather poor integration (and yes, the fact that they tried to funnel desktop users through the "tablet" part to pent up demand for apps and attract developers).
Has the F-Secure tried to, as article mentions, disable the Mi Cloud account? Probably not. Because it wouldn't have been in the news then.
I know this is slashdot, but if you start making claims about what is *not* in the article, could we at least expect you to look for it yourself?
F-Secure saw the communication even before they created a Mi cloud account.
The security company said that it took a brand new smartphone from the box with no prior set-up or cloud connect allowed. It then followed the following steps:
- Inserted SIM card
- Connected to WiFi
- Allowed the GPS location service
- Added a new contact into the phonebook
- Send and received an SMS and MMS message
- Made and received a phone call"We saw that on startup, the phone sent the telco name to the server api.account.xiaomi.com. It also sent IMEI and phone number to the same server," F-Secure said.
I do not often say this on
Oh, huh. SecureBoot isn't Palladium; it's some new-fanegaled UEFI feature.
It looks like you can insert new keys into the SecureBoot DB with dpkg-reconfigure secureboot-db in Ubuntu, so sufficient OS-level access should allow for bypassing SecureBoot in UEFI. This is a little easier than it was with the TPM, I guess.
No, not unless the OEM did *not* follow the specs. If they followed the UEFI specs this should not be possible.
On top op that, it is a specific requirement for "Designed for Windows 8 certification" that the keys cannot be manipulated from the operating system.
The only way to change the key store is through physical (like in at the keyboard) control of the UEFI firmware in the pre-boot "maintenance mode" *or* through a firmware upgrade. Firmware upgrades *must* be signed as well, so no, you can not use that avenue either.
OEMs who designs their system with UEFI will certainly make sure to meet those requirements.
Windows 8 Secure boot is a pretty flimsy facility that says 'yep, this code was blessed by microsoft'. It does nothing to vouch for whether the configuration leading up to or the configuration of the payload is what you actually want (e.g. a specific user expects they hve put in Windows 8, but instead Red Hat loading with malicious configuration would be a sort of misbehavior that SecureBoot does nothing for).
UEFI secure boot validates everything (configuration) until the boot-loader load. The boot-loader sits in signed cabinet files and the UEFI firmware will not load the boot-loader if the boot-loader cabinet files do not check out (invalid signature).
The boot-loader will check the operating system - Windows 8 - core before relinquishing control of the boot process to the OS. Windows 8 sits in signed cabinet files and the boot-loader will not boot the OS if the files have been tampered with (invalid signatures).
Right after the kernel has started - relying *only* on information from the signed cabinet files and signed kernel drivers (all drivers which load in kernel space in Windows 64 bit versions must be signed), the antivirus providers will be allowed to load. AV must *also* be signed by MS to be allowed to load at this stage. The AV can now control loading the rest of the OS. Still, any kernel level drivers *must* be signed.
You are correct that the boot-loader will also boot other signed OSes - like RH Linux and those *could* be used to start Win8 or some other OS in a VM and under control of the "signed" OS. You can bet that MS has requirements that the booting of non-Windows OS is obvious (something must happen at the screen clearly identifying the OS being booted).
But at the whole, UEFI Secure Boot along with Windows 8 signed boot-loader and OS is *very* hard to circumvent. I haven't heard of any successful attack yet. There was some spin on an attempt that did not use UEFI Secure Boot (it used BIOS).
It should be attached to a network fire-walled off from the Internet and only accessible if you are on the local LAN.
But it is based on Linux, right? Why would it need to be fire-walled off from the Internet when so many Linux servers and appliances are on the Internet?
The one day you'd sell your soul for something, souls are a glut.
