Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

+ - Serious Network Function Vulnerability Found In Glibc 1

Submitted by Anonymous Coward
An anonymous reader writes "A very serious security problem has been found and patched in the GNU C Library (Glibc). A heap-based buffer overflow was found in __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() function calls. A remote attacker able to make an application call to either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the program. The vulnerability is easy to trigger as gethostbyname() can be called remotely for applications that do any kind of DNS resolving within the code. Qualys, who discovered the vulnerability (nicknamed "Ghost") during a code audit, wrote a mailing list entry with more details, including in-depth analysis and exploit vectors."

+ - Why Screen Lockers On X11 Cannot Be Secure->

Submitted by jones_supa
jones_supa (887896) writes "One thing we all remember from Windows NT, is the security feature requiring the user to press CTRL-ALT-DEL to unlock the workstation (this can still be enabled with a policy setting). The motivation was to make it impossible for other programs to mimic a lock screen, as they couldn't react to the special key combination. Martin Gräßlin from KDE team takes a look at the lock screen security on X11. On a protocol level, X11 doesn't know anything of screen lockers. Also the X server doesn't know that the screen is locked as it doesn't understand the concept. This means the screen locker can only use the core functionality available to emulate screen locking. That in turn also means that any other client can do the same and prevent the screen locker from working (for example opening a context menu on any window prevents the screen locker from activating). That's quite a bummer: any process connected to the X server can block the screen locker, and even more it could fake your screen locker."
Link to Original Source

+ - Windows 10: Charms Bar Removed, No Start Screen for Desktops->

Submitted by jones_supa
jones_supa (887896) writes "Late last week, Microsoft pushed out a new build (9926) of Windows 10 to those of you who are running the Technical Preview. The latest version comes with many new features, some easily accessible, others bubbling under, but two big changes are now certain: the Charms bar is dead, and Start Screen for large devices is no more. Replacing the Charms bar is the Action Center, which has many of the same shortcuts as the Charms bar, but also has a plethora of other information too. Notifications are now bundled into the Action Center and the shortcuts to individual settings are still easily accessible from this window. The Start Screen is no longer present for desktop users, the options for opening it are gone. Continuum is the future, and it has taken over what the Start Screen initiated with Windows 8."
Link to Original Source

Comment: Re:DirectX is obsolete (Score 1) 131

by jones_supa (#48903071) Attached to: DirectX 12 Lies Dormant Within Microsoft's Recent Windows 10 Update
Now you expanded the discussion to the GPU driver running on the CPU. The original claim was that "shaders are programs that run on your GPU at kernel level with full DMA access to your computer". But other than that, sure, I agree with you: the OpenGL stack and the GPU driver are a potential minefield.

Comment: Re:Why do Windows programs just run? (Score 2) 123

by jones_supa (#48893577) Attached to: Linus Fixes Kernel Regression Breaking Witcher 2

Do you mind if I ask what flavor of Linux you were running, what the desktop(s) were and what were the issues you were getting?

That is usually followed by "ah yes, that particular distro is known to be broken, no wonder you were having problems". :)

There have been various issues like the GP comment described, but I won't write a long rant about them. Right now, if I sent a letter to Santa Claus and wanted to have just one issue solved, it would be the problem where the laptop brightness goes in multiple steps under Debian-based distros such as Mint and Ubuntu. Apparently this is because there can be multiple listeners to the backlight event (GPU driver, ACPI driver, OS, BIOS...) and they all do the adjustment without consuming the event. Anyone can observe this problem on a laptop. This is so basic stuff that it cannot be consistently broken like this.

Fix the brightness adjustment. Doooo it. No, I won't do the engineering work to fix it. I have other problems to solve than personally fixing my OS bugs. Windows works fine.

What hath Bob wrought?

Working...