I find interesting that GNOME Screensaver's security depends on it to not crash.
Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process.
The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver will spawn kscreenlocker again but this time with software rendering (just in case it crashed due to graphics driver issue). If kscreenlocker crashes four times then KDE Session Management Server gives up, stops respawning kscreenlocker and simply draws the following text on the screen.
The screen locker is broken and unlocking is not possible anymore.
In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
log in and execute the command:
loginctl unlock-session %1
Afterwards switch back to the running session (Ctrl+Alt+F%2).
If ksmserver itself crashes then the entire session closes.
I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
In Windows it’s also good. The way it works is follows.
The OS support multiple desktops. Similar to files or registry keys, desktops have security descriptors attached (a data structure keeping who’s the owner, and optionally listing users/groups with their respective permissions on the object being controlled).
To do anything on a desktop, like create windows, paint stuff, or interact with windows on that desktop, user doing that is required to pass an access check against the security descriptor of the desktop. If failed, these GUI-related functions gonna return “access denied” status code instead of doing anything.
The login screen is simply rendered on a separate desktop. That desktop has restrictive security descriptor, most users don’t have permissions to interact with them. UAC prompts are also displayed on another desktop, that’s how it’s impossible to automate them from within a program who triggered the UAC prompt.
BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.
>I'm not sure why GNOME screensaver cannot do something like this.
This actually is fixed in upstream GNOME because the screensaver is now built into the shell. The problem here is exclusively with cinnamon-screensaver and other components derived from gnome-screensaver, which is unmaintained and upstream GNOME considers it obsolete.
jwz has a lot to say about complex graphical toolkits/desktop environments and their complex locking mechanisms. It's an interesting series of posts.
If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
I actually had this happen around Christmas (using Manjaro). I had no idea what the message really meant or what caused it. The instructions were at least clear enough to get back into the running session, which is far better than, say, most of GNOME's crap.
I have no idea why GNOME is the default DE for the big distros (Redhat et al, Ubuntu). Technically it's evidently inferior, it had substandard ergonomics and features like accesibility services. I really dont get it.
The Gnome screensaver lock is only a fluffy fake security mechanism. It's not real security.
I've had many instances where my CPU was bogged down and after hitting the keyboard I could use the computer for a good several seconds before the lock screen popped up asking for a password.
> I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
That is an option Linux Mint is considering[0] among other options.
Does anyone know why lockscreens in Linux have been such a joke? I remember trying Ubuntu couple years ago and when waking up my laptop it would show me my entire desktop with all the information displayed right there in the open for about 10-20 seconds before suddenly engaging the lockscreen. All you had to do was close the lid and open it again and you could just copy whatever was on the screen before the lock screen appeared. I guess it's because the lockscreen was a separate process that had to start up? Still, what an awful awful design.
Can anyone explain why a crash in xscreensaver results in the computer being unlocked?
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
Because X11 is such a joke. The problem is solved by wlroots and layer-shell, other Wayland compositors probably have similar things. Swaylock works 100%ly reliable until now (For me). I had problems with every other X11 screenlocker I used in the past. My unusual setup with a docking station and two monitors on it often caused crazy bugs.
I don't dispute the bad design, but FYI, there was also a very recent exploit for accessing bitlocker drives on Windows without login credentials, making use of accessibility features on the lockscreen.
For x lockscreens this is solved by making sure the lock launches _before_ the system is suspended, I'm not sure how many distros do it like that though.
In the past I also had some information leaks with an Nvidia discrete graphics card, which seemed to not clear its RAM or something. I think it even persisted over restarts or similar complete session terminations. So I assume, driver issues may play into this too.
Years ago I taught a high school typing class in a K-12 school. The school didn't have the funds to get a commercial typing program so I wrote my own typing program. It evolved over time with features to help me track the students' progress etc. One day we had a school open house where all the parents could come to school. We had a bunch of different activities set up in different classrooms and I ended up getting assigned to the 3rd grade classroom to set up my typing program so anyone coming through could test their typing speed. It was a DOS program and I didn't want people using anything other than my typing program, so I modified it so you couldn't quit the typing program. Over the course of the day the 3rd graders were hanging out in their homeroom not really doing anything productive. Of course the computer was a novel attraction and they were just smashing keys and exploring my program's UI. Eventually at one point I noticed that they had somehow crashed my program with a segfault in what had otherwise become a pretty stable piece of software. To this day I have absolutely no idea what the bug was.
> The school didn't have the funds to get a commercial typing program so I wrote my own typing program.
Off-topic, but:
It seems absurd, to me, that such a conclusion could ever be reached. Obviously, from my perspective, the economies of scale, the infrastructure, overhead, and institutional resources available to programmers at a dedicated software development firm would produce an application at better quality per dollar (however you measure it) than a high school teacher in their off-hours. To me it seems that it's certainly not cheaper for us as a society, as a species, and only appears so because you are under-paid. If you were paid your actual worth, the school would say "we don't have the funds to develop this in-house, and had to buy a commercial typing program off-the-shelf, despite its loose fit for our use case."
How can we, as rational members of society, abide this?
Are you sure it was a segfault? DOS did not have any memory protection, so segfault would be impossible. Or maybe you used some protected mode DOS extender?
Mi kid got around the lock screen of my mac. Twice.
It was 4-5 years ago when he was about 2. I had a 15+ character random password (a generated one including symbols etc) so the chances of him being lucky were rather slim. He was just mashing button on the lock screen for less than a minute when boom, I was suddenly signed in. The first time I thought it was a fluke. Then it happened again after a couple of months. After that I took my phone, sat him behind my computer and started to record him playing with the buttons but it never happened again and my hopes of getting a bug bounty from Apple vanished :(
My kid (3 years old then) found an issue in the MacOS lock screen as well. It didn't result in a bypass, but a "Spinning Beach Ball of Death". I could then reproduce it and even filed an issue, but only I could reproduce (and one funny response was: "Why would you want a screen shot of the screen sleeping? It would just be black." - well tell that to my kid): https://discussions.apple.com/thread/7598463
People have been fuzzing user interfaces since the 80s. It was used for developing MacPaint and MacWrite in Apple's original Macintosh. Quote Wikipedia:
> In 1983, Steve Capps at Apple developed "The Monkey", a tool that would generate random inputs for classic Mac OS applications, such as MacPaint [0]. The figurative "monkey" refers to the infinite monkey theorem which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will eventually type out the entire works of Shakespeare. In the case of testing, the monkey would write the particular sequence of inputs that will trigger a crash.
As others have pointed out, you are describing fuzzing but rather than purely random you’ve trained your fuzzer on a particularly troublesome set of random variables ;-)
What context? Reading that issue, the content seems to be:
1: jwz says if you add accessibility features to a text box, make sure they don't have any bugs that can kill a process, since that will break screen lockers
2: Cinnamon adds a buggy accessibility feature to a text box that lets you crash the screen locker
3: Github user clefebvre says something along the lines of "why is jwz being so negative >:("
Well... you did exactly what he told you not to do. If you're going to add accessibility features to a text box, you need to not screw it up. If you screw it up, then it breaks the screen locker for every user in the world, including the 99% of people who will never use the accessibility features.
If you make an obvious, stupid mistake, people will make fun of you. Complaining that people are making fun of you won't do much. Try, instead, to not make the obvious stupid mistake?
From the issue:
>With that said, I have on message for JWZ. Don't be that guy. It's too easy to just tell people no to cross the street. Work with us on building that safest path.
Huh? What? He wrote xscreensaver 20 years ago. He's supposed to fix buggy code written by other people until he dies?
Why is it his responsibility to fix your code? The distro extended his program, the extension broke. You can either ignore the problem, remove the extension, or fix the extension. None of these things sounds like xscreensaver's problem!
Physlock works comparatively well, but nothing can stop the omniscient stupidity of, eg ctrl-alt-del 10x (or similar) invoking reboot, which I've found no method of preventing. The general attitude encountered when seeking a solution to this madness is "if someone has physical access, you're pwned anyway", which is also supremely unimaginative and omnisciently stupid. This has gnawed at my cranial portions for years, and I now speak forth in due fury.
In middle school long ago, I was using one of the library search computers. They ran Windows XP and were locked down to the point where you couldn't open anything except the software that was running and you had no access to the desktop. One day I was rapidly mashing the "Search" button in the native book-searching software they were using - for no reason at all - and it suddenly opened an Explorer window out of nowhere showing everything in the filesystem. I could reproduce it easily with rapid-enough clicks. I still have no idea why that happened.
This reminds me of the classic XP login screen bypass by opening the help dialog, then the print dialog, then searching for a file to open for printing, and then executing 'explorer.exe' (I might be misremembering, this is quite a while ago).
I also remember figuring out how to share my USB key as a network drive to other users. Many fun middays were had blasting around in Halo or Soldier of Fortune II with like 10 friends, although less fun was had when our school's sysadmin found some lingering cache files that were owned by my id.
Classic thing was to write file:///C:\ (or something similar, I do not remember it anymore) on computers with only kiosk mode IE on them to access the local file system. :)
Oh man this brings back so much nostalgia for the old school computer exploits we used to find.
Only approved programs software was supposed to run but you could actually run anything as long as the .exe was on the desktop.
7-zip would let you explore the entire network drive, including teachers folders that we didn't have access to.
Unplugging the reconnecting the Ethernet cable wouldn't reconnect you to the teachers monitoring software.
We had a zip filled with games like Starcraft 2, Quake 3, Halo CE that was hidden on the shared network drive that kids around the school would use to play and LAN with each other.
My daughter was 1ish at the time, and I sat her down while I grabbed something from the fridge. Windows 98, locked.
When I came back the screensaver was on, the password dialog was still up, but the desktop was fully functional in front of it. I could navigate, open applications, and everything else.
Still no idea how she did it, but that’s not the first or last time she surprised me :)
This reminds me of when I was about 14. I had a Tamagotchi which I had for a record amount of time. My niece, about 2 at the time wanted to see it so let her hold it. Within 1/2 a second, she squeezed both buttons at the same time and crashed it.
My daughter managed to buy 24 hours of football pass with NowTV by pressing the same button repeatedly on the remote within about 5 seconds.
My daughter, whilst roaming in the US from the EU somehow managed to get unlimited data after her initial miserly roaming allowance was used up.. simply by switching airplane mode on and off repeatedly until data worked.
I was stressing getting back home to a huge bill, but kept the "all chargeable services have been stopped" messages just in case.
It uses a compiler pass to insert code to branch points functions calls etc.
I think it uses genetic algorithms to increase coverage by changing the data.
I have used AFL a few times casually in some personal projects, and it has always performed quite well for me. Of course, there are a lot of weird cornercases which would not occur on real-world (non-adversarial) inputs, but it also found some very real bugs.
(For example, I once wrote a hash table implementation where the insertion and resizing procedures had slightly different views on wraparound, causing failures on very specific inputs. Another time, I wrote some code to buffer out-of-order messages, which would only occur due to a race condition. It was wrong. Both times I had thought carefully about the code, and the bugs would have been painful to discover otherwise.)
Somewhat similar for web UIs: Quickstrom is a tool that lets you define a set of conditions that should hold (e.g. "there should always be an 'Add todo' button"), and then it'll simulate behaviour that might break that condition.
Another tangentially linked anecdote. We had build artefacts stored on a Samba shared drive, that were write protected, since some people regularly used to move them instead of copying them. Then one day, the latest build was gone again. We asked around to see whether someone had purposefully removed the build, but no. Turns out someone on Windows 10 had tried to cut and paste the file, but his computer had crashed before pasting. Apparently the permissions were only checked on paste, but the file was unlinked on cut?
i don't think these permissions are enforced client side... I also think write and delete are separate permissions on windows and i am pretty sure i never lost a file on accidentally doing only the first halt of a cut and paste aka move... so i conclude this "someone" either had nothing to do with the incident or removed it by accident...
Something about this exchange was extremely pleasing and calming to read, maybe I'm irony poisoned from overly loud social media. But this was so nice to read through.
A pleasant bugreport with no judgement or demands.
And a quick response by the maintainer who shows thank, is focused on a clear outcome, and shows the progress transparently.
I've seen too many bugreports where one, or both actors behave vastly different. This one here should be a reference for anyone involved in 'bugreports' in some way.
Unless there's something unbelievably wacky going on, this is why people use formal verification.
If you can describe your program as a state machine, you can ask an SMT solver to find any transitions that break stuff. Unfortunately it's a lot harder to do for software than hardware because of the plasticity people expect from the former, but works it was it's really nice.
Keep in mind that screensavers aren't the only untested dumpster fire on Linux Desktops (or ~ distributions in general).
The whole desktop architecture is out of date. I wouldn't be surprised if someone argued that screensavers aren't important because it's just your user data exposed, the root account is still safe!
I enjoy to see my kid breaking software, POS terminals and causing ATMs to throw error windows. Nothing critical, just funny how random screen touching and keyboard mashing drives “serious” software crazy.
Fool-proof and child-proof software is yet to come.
3 y.o. figure it out better than my parents because it seems their mindset is ‘do all the things’ to see what the i/o structure is. Their brain is built that way when they are so young.
Not really the same, but I had fun back in high school. Finding the Novell messaging utility that let me send a message to (IIRC) anyone in the school board currently logged in, though not anonymously.
Using some a couple lines of VBScript to change a couple registry entries (computers didn't persist storage anyways) you could also give your local admin privileges, to install stuff. That one got me in a touch of trouble, and I lost my account for a couple weeks while they "looked at my files", because I stored it on my network drive folder.
Linux Mint, and whatever it's built on, has been disappointing to me. The most worrying thing I've experienced is that, when waking up from sleep, the unlocked screen will sometimes flash before showing the lockscreen. That is a huge no-no and really betrays the fallibility of whatever security measures are employed.
I remember finding a very similar issue with XDM on a Sun 3/60 back in about 1992. Just mash the keyboard while in the 'password' field and it would eventually drop a root shell. Oops!
The first computer I ever bricked was a my father's work laptop running Windows 95. I was a toddler and wanted to press the buttons. Good to see the kids are still at it!
That reminded me of the Linux GRUB2 bug where you could press Backspace key 28 times and bypass all security. [1]
>The source of the vulnerability is nothing but an integer underflow fault that was introduced with single commit in Grub version 1.98 (December 2009) – b391bdb2f2c5ccf29da66cecdbfb7566656a704d – affecting the grub_password_get() function.
A well known reference, Eric Raymond's "jargon file" a.k.a. "hacker's dictionary" offers 9 definitions, much broader and seemingly older than keypress timings: http://catb.org/~esr/jargon/html/H/hack.html
The original definition of "hacking" was "hacking code together". Move fast and break things. There are a lot of us OG and TNG hackers here. It's kind of the SV spirit.
"Cracker" is the term used commonly - as in "crack the nut"; i.e. gain access to systems / break copy protection etc. Then you have the phone guys, the phreakers, whistling for free calls.
GlitchMr|5 years ago
Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process.
The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver will spawn kscreenlocker again but this time with software rendering (just in case it crashed due to graphics driver issue). If kscreenlocker crashes four times then KDE Session Management Server gives up, stops respawning kscreenlocker and simply draws the following text on the screen.
If ksmserver itself crashes then the entire session closes.I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
Const-me|5 years ago
The OS support multiple desktops. Similar to files or registry keys, desktops have security descriptors attached (a data structure keeping who’s the owner, and optionally listing users/groups with their respective permissions on the object being controlled).
To do anything on a desktop, like create windows, paint stuff, or interact with windows on that desktop, user doing that is required to pass an access check against the security descriptor of the desktop. If failed, these GUI-related functions gonna return “access denied” status code instead of doing anything.
The login screen is simply rendered on a separate desktop. That desktop has restrictive security descriptor, most users don’t have permissions to interact with them. UAC prompts are also displayed on another desktop, that’s how it’s impossible to automate them from within a program who triggered the UAC prompt.
BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.
cycloptic|5 years ago
This actually is fixed in upstream GNOME because the screensaver is now built into the shell. The problem here is exclusively with cinnamon-screensaver and other components derived from gnome-screensaver, which is unmaintained and upstream GNOME considers it obsolete.
dr_cypher|5 years ago
inetknght|5 years ago
brnt|5 years ago
wrsh07|5 years ago
cuillevel3|5 years ago
anticensor|5 years ago
dheera|5 years ago
I've had many instances where my CPU was bogged down and after hitting the keyboard I could use the computer for a good several seconds before the lock screen popped up asking for a password.
noisy_boy|5 years ago
That is an option Linux Mint is considering[0] among other options.
[0]: https://github.com/linuxmint/cinnamon-screensaver/issues/354...
awestroke|5 years ago
unknown|5 years ago
[deleted]
gambiting|5 years ago
astrange|5 years ago
https://news.ycombinator.com/item?id=25801693
josephg|5 years ago
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
bionade24|5 years ago
Edit: For me stuff
boblivion|5 years ago
smolder|5 years ago
Illniyar|5 years ago
pojntfx|5 years ago
3np|5 years ago
f1refly|5 years ago
monopoledance|5 years ago
unknown|5 years ago
[deleted]
unknown|5 years ago
[deleted]
Kelamir|5 years ago
minxomat|5 years ago
globular-toast|5 years ago
My guess is that these lock screens are all bolted on afterwards rather than being in the design from the ground up.
anthk|5 years ago
mightybyte|5 years ago
rexpop|5 years ago
Off-topic, but:
It seems absurd, to me, that such a conclusion could ever be reached. Obviously, from my perspective, the economies of scale, the infrastructure, overhead, and institutional resources available to programmers at a dedicated software development firm would produce an application at better quality per dollar (however you measure it) than a high school teacher in their off-hours. To me it seems that it's certainly not cheaper for us as a society, as a species, and only appears so because you are under-paid. If you were paid your actual worth, the school would say "we don't have the funds to develop this in-house, and had to buy a commercial typing program off-the-shelf, despite its loose fit for our use case."
How can we, as rational members of society, abide this?
BruiseLee|5 years ago
tauntz|5 years ago
It was 4-5 years ago when he was about 2. I had a 15+ character random password (a generated one including symbols etc) so the chances of him being lucky were rather slim. He was just mashing button on the lock screen for less than a minute when boom, I was suddenly signed in. The first time I thought it was a fluke. Then it happened again after a couple of months. After that I took my phone, sat him behind my computer and started to record him playing with the buttons but it never happened again and my hopes of getting a bug bounty from Apple vanished :(
thomasmg|5 years ago
matsemann|5 years ago
apexalpha|5 years ago
unknown|5 years ago
[deleted]
slim|5 years ago
bjoli|5 years ago
On the previous version I believe he managed to unlock the computer as well, just by hammering the keyboard.
diegoperini|5 years ago
2: Use ML to learn how to simulate it.
3: Sell it as a service, labeling it KaaS.
4: Profit, then go to jail because of a misunderstanding.
But seriously, is there such a tool to automate this?
segfaultbuserr|5 years ago
> In 1983, Steve Capps at Apple developed "The Monkey", a tool that would generate random inputs for classic Mac OS applications, such as MacPaint [0]. The figurative "monkey" refers to the infinite monkey theorem which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will eventually type out the entire works of Shakespeare. In the case of testing, the monkey would write the particular sequence of inputs that will trigger a crash.
Read the story here:
https://www.folklore.org/StoryView.py?story=Monkey_Lives.txt
fabianhjr|5 years ago
rusk|5 years ago
PartiallyTyped|5 years ago
bjoli|5 years ago
smarx007|5 years ago
But this is pretty impressive as well!
carapace|5 years ago
Qub3d|5 years ago
sbierwagen|5 years ago
1: jwz says if you add accessibility features to a text box, make sure they don't have any bugs that can kill a process, since that will break screen lockers
2: Cinnamon adds a buggy accessibility feature to a text box that lets you crash the screen locker
3: Github user clefebvre says something along the lines of "why is jwz being so negative >:("
Well... you did exactly what he told you not to do. If you're going to add accessibility features to a text box, you need to not screw it up. If you screw it up, then it breaks the screen locker for every user in the world, including the 99% of people who will never use the accessibility features.
If you make an obvious, stupid mistake, people will make fun of you. Complaining that people are making fun of you won't do much. Try, instead, to not make the obvious stupid mistake?
From the issue:
>With that said, I have on message for JWZ. Don't be that guy. It's too easy to just tell people no to cross the street. Work with us on building that safest path.
Huh? What? He wrote xscreensaver 20 years ago. He's supposed to fix buggy code written by other people until he dies?
Why is it his responsibility to fix your code? The distro extended his program, the extension broke. You can either ignore the problem, remove the extension, or fix the extension. None of these things sounds like xscreensaver's problem!
eth0up|5 years ago
https://linuxcommandlibrary.com/man/physlock
herpderperator|5 years ago
jorvi|5 years ago
I also remember figuring out how to share my USB key as a network drive to other users. Many fun middays were had blasting around in Halo or Soldier of Fortune II with like 10 friends, although less fun was had when our school's sysadmin found some lingering cache files that were owned by my id.
Haemm0r|5 years ago
Hoboburger|5 years ago
Only approved programs software was supposed to run but you could actually run anything as long as the .exe was on the desktop.
7-zip would let you explore the entire network drive, including teachers folders that we didn't have access to.
Unplugging the reconnecting the Ethernet cable wouldn't reconnect you to the teachers monitoring software.
We had a zip filled with games like Starcraft 2, Quake 3, Halo CE that was hidden on the shared network drive that kids around the school would use to play and LAN with each other.
joshspankit|5 years ago
My daughter was 1ish at the time, and I sat her down while I grabbed something from the fridge. Windows 98, locked. When I came back the screensaver was on, the password dialog was still up, but the desktop was fully functional in front of it. I could navigate, open applications, and everything else.
Still no idea how she did it, but that’s not the first or last time she surprised me :)
benibela|5 years ago
throwanem|5 years ago
In general, the way you secured a Windows 9x box was by locking the door to the room it was in.
martin-adams|5 years ago
My daughter managed to buy 24 hours of football pass with NowTV by pressing the same button repeatedly on the remote within about 5 seconds.
So a crash like this doesn't surprise me.
_puk|5 years ago
My daughter, whilst roaming in the US from the EU somehow managed to get unlimited data after her initial miserly roaming allowance was used up.. simply by switching airplane mode on and off repeatedly until data worked.
I was stressing getting back home to a huge bill, but kept the "all chargeable services have been stopped" messages just in case.
My final bill was £300+, zeroed.
Phew!
josefx|5 years ago
That was probably not a crash, on some that did a partial reset.
kuter|5 years ago
For example LLVM's lib fuzzer uses instrumentation to track code coverage and mutates data to find invalid behaviour.
https://llvm.org/docs/LibFuzzer.html
It uses a compiler pass to insert code to branch points functions calls etc. I think it uses genetic algorithms to increase coverage by changing the data.
There are others that work in similar ways one of them is. https://github.com/google/AFL
cuillevel3|5 years ago
https://media.ccc.de/v/30C3_-_5499_-_en_-_saal_1_-_201312291...
suyjuris|5 years ago
(For example, I once wrote a hash table implementation where the insertion and resizing procedures had slightly different views on wraparound, causing failures on very specific inputs. Another time, I wrote some code to buffer out-of-order messages, which would only occur due to a race condition. It was wrong. Both times I had thought carefully about the code, and the bugs would have been painful to discover otherwise.)
Vinnl|5 years ago
See https://quickstrom.io/
(I haven't used it myself yet, but it looks interesting.)
passivate|5 years ago
Leherenn|5 years ago
mercora|5 years ago
dluan|5 years ago
berkes|5 years ago
And a quick response by the maintainer who shows thank, is focused on a clear outcome, and shows the progress transparently.
I've seen too many bugreports where one, or both actors behave vastly different. This one here should be a reference for anyone involved in 'bugreports' in some way.
mhh__|5 years ago
If you can describe your program as a state machine, you can ask an SMT solver to find any transitions that break stuff. Unfortunately it's a lot harder to do for software than hardware because of the plasticity people expect from the former, but works it was it's really nice.
cuillevel3|5 years ago
Start kiosk mode fullscreen app as a lock screen -> if app exits -> show desktop
scalableUnicon|5 years ago
12312311241231|5 years ago
The whole desktop architecture is out of date. I wouldn't be surprised if someone argued that screensavers aren't important because it's just your user data exposed, the root account is still safe!
nrvn|5 years ago
Fool-proof and child-proof software is yet to come.
Hire QA kids.
mensetmanusman|5 years ago
I see similar behavior with smartphones.
3 y.o. figure it out better than my parents because it seems their mindset is ‘do all the things’ to see what the i/o structure is. Their brain is built that way when they are so young.
0xTJ|5 years ago
Using some a couple lines of VBScript to change a couple registry entries (computers didn't persist storage anyways) you could also give your local admin privileges, to install stuff. That one got me in a touch of trouble, and I lost my account for a couple weeks while they "looked at my files", because I stored it on my network drive folder.
lostgame|5 years ago
uoaei|5 years ago
viro|5 years ago
Havoc|5 years ago
boomboomsubban|5 years ago
technothrasher|5 years ago
etxm|5 years ago
The QA team had a test they called “the elbow test” where they did exactly this.
Just kind of put their elbow randomly on the keyboard to see if stuff would break.
causalmodels|5 years ago
Darmody|5 years ago
Jerry2|5 years ago
>The source of the vulnerability is nothing but an integer underflow fault that was introduced with single commit in Grub version 1.98 (December 2009) – b391bdb2f2c5ccf29da66cecdbfb7566656a704d – affecting the grub_password_get() function.
[1] https://thehackernews.com/2015/12/hack-linux-grub-password.h...
scotty79|5 years ago
No dialogs or confirmations. Just black screen and computer rebooting.
WhompingWindows|5 years ago
viro|5 years ago
atomize|5 years ago
z29LiTp5qUC30n|5 years ago
inetknght|5 years ago
Color me surprised! /s
exabrial|5 years ago
codeulike|5 years ago
plumeria|5 years ago
rblion|5 years ago
smooth__|5 years ago
smashes keys
Unlocks
fmakunbound|5 years ago
johnwayne117|5 years ago
chromatin|5 years ago
greypowerOz|5 years ago
blackrock|5 years ago
amid34d|5 years ago
[deleted]
amid34d|5 years ago
[deleted]
stelf|5 years ago
snarfy|5 years ago
idiocrat|5 years ago
s_gourichon|5 years ago
( see also http://catb.org/~esr/jargon/html/index.html and https://en.wikipedia.org/wiki/Jargon_File )
radicalbyte|5 years ago
"Cracker" is the term used commonly - as in "crack the nut"; i.e. gain access to systems / break copy protection etc. Then you have the phone guys, the phreakers, whistling for free calls.