Live data from Hacker News

Null

popey.com

111–120 of 196 posts

Re: Null

#111

Earlier quoted context omitted.

Found some GitHub issues [1] with something similar: an enterprise firewall blocking a repo because it contained the string "arglebargleglopglyf" [2] in some tests. The text was flagged as malicious because of its presence in the repo github.com/wireghoul/htshells [3]. However, the whole point of the word in the htshells repo is that it's an invalid command that breaks Apache, so it could have been almost any random…

This one from link 3 caught my eye: "".__class__.__mro__[2].__subclasses__()[40]("/etc/passwd").read() Looks to be a Python 2 specific way of trying to read a file in a sneaky way. I say Python 2 specific because Python 3 strings only have 2 supertypes now, so __mro__[2] is out of range, but __mro__[1] is 'object', and I'm guessing they were going for a file like class, but right now object.__subclasses__()[40] point…

    $ python2
    >>> "".__class__.__mro__[2].__subclasses__()[40]("/etc/passwd").read()
    'root:x:0:0:root:/root:/bin/bash\n ...
yep, there it is.

Re: Null

#112
post #28
post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

Because it's just software. You can just change it and it costs nothing. Redesigning the powertrain in your car to be resilient when non-gasoline is introduced into the combustion chamber is expensive. Redesigning software is just changing some code; you just need to say something like 'Zoom. Enhance.' or 'It's a Unix system! I know this!' and it will take care of itself after a dozen rapid random keystrokes.

Re: Null

#113
post #98

Earlier quoted context omitted.

I'm surprised about Scunthorpe, if any name with a profanity substring would trigger the filter I'd have thought this issue would be more common than Scunthorpe.

Yeah, such a filter would be a mbuttive problem due to all the mimanures.

This could exists a fun puzzle genre, replacing substforbidds of words with synonyms. Perhaps with muloanle dened itefractionns. Could even have replacementb agrosb lade boundaries.

Re: Null

#114
post #28

Earlier quoted context omitted.

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

Holding down the button for your hazard lights should not break your car. Holding down a key should not crash an app.

Holding down a pedal probably is going to crash your car.

Re: Null

#115

Earlier quoted context omitted.

A favourite technique of one of my colleague's was just to mash the keyboard randomly to see if the app breaks. It's very crude and not at all foolproof. For the lack of sophistication it's shockingly effective at highlighting a huge amount of assumptions we make about how software is / can be used.

This even has a name, "monkey testing". Basically some software that pretends to be a monkey in front of a computer and mashes random buttons and keys to make the application behave badly. Usually you only care about the application not breaking in monkey tests. Can be used similarly to "fuzzing" but for UIs as well, see Gremlins.js: https://marmelab.com/blog/2020/06/02/gremlins-2.html

This is how, at age 12 or so, I discovered in the old Windows game “Chip’s Challenge” that you could cheat and unlock (nearly all) levels.

If you tried ctrl+n (I think), you could advance to the next level, but only if you had beaten the current level or had the pass code for the level. In a bout of frustration, I rando-mashed the keyboard and advanced to the next level, and could then ctrl+n to the last level! I could reproduce the effect, but never worked out the actual combination that unlocked it. Good times :)

Re: Null

#116
Reminds me of a QA buddy. One day at the crosswalk, he decided to, I believe, hold the button. For the whole wait. He apparently broke the entire intersection’s lights and a repair crew came out. He was unable to reproduce it after.

Re: Null

#117
post #77
post #11

People like that is the reason why this list was created https://github.com/minimaxir/big-list-of-naughty-strings/blo... My personal favorite is this one though "If you're reading this, you've been in a coma for almost 20 years now. We're trying a new technique. We don't know where this message will end up in your dream, but we hope it works. Please wake up, we miss you.",

I can get why testing for "Jimmy Clitheroe" and "Horniman Museum" , but can't make a reason for "Linda Callahan" .

Any idea why "Lightwater Country Park" is on the list?

Re: Null

#119
post #24

Perl 5 has a taint mode built into the language. If enabled, it forces the developer to untaint every bit of user-controllable data (by running it through a pattern match) before doing anything dangerous with it. I can't believe that this isn't a standard feature in all languages.

You can do this with any language with a type system by wrapping reads with a 'Tainted' type. ie: fn safe_read(path: str) -> Tainted { Tainted(unsafe_read(path)) } And then you can apply functions to Tainted or whatever type that convert it into something structured / validated. So long as your functions only take in those validated types (ie: you do not write functions that take str) you can ensure that new reads wi…

You can do some actually useful stuff with a real type system, instead of replicating Perl's stupidity.

For example, you can convert the input into a safe representation, suitable for the exact place you'll be using the string, instead of "validating" it.

Re: Null

#120
post #28
post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

There's a few answers here.

First off, we expect all things to be as resilient and reliable as makes sense via a cost benefit analysis. If it's cheap to fix, and expensive not to fix, we expect it to be done. If it's expensive to fix and cheap to ignore, we expect it not to be done. And of course, if it's impossible to fix, we definetly expect it to be ignored. :)

So, we expect that cars should NOT catch fire when rear-ended, because it's possible to design them not to do so, it's not that expensive to design them not to do so, and innocent people could be seriously harmed through no fault of their own.

But water in a gas tank? I can't think of a way to stop someone doing that. And it would just disable the car if you did it. And since cars have locking fuel tank covers, you're really limited in your ability to maliciously harm other peoples cars.

So in the case of cars "explodes when rear ended" is not okay but "stops driving when you fill the tank with water" is okay.

Software, by its design, is often more fixable than other things. You can filter the inputs to a log in form whereas you can't really filter "things people might put in their kitchen blender".

Second, note that software is, bluntly, a lot less resilient than most things. I've got a hammer sitting in my garage, and it's just going to sit there until I do something with it. It won't randomly stop working, it won't auto-update to a version that is incompatible with my nails, it won't be remotely hijacked by Russian scammers to break into local businesses, it doesn't need patching. There will never be a CVE for this hammer. :) I've had it for many, many years, and I'll have it for many many more, and it will be just as good a hammer in 10 years as it was when I got it. We can't say the same thing for software. And since software is just way more of a dumpster fire than "normal" things, we have to expect that more work will need to be done to counteract that.

(There is, as always, at least one relevant XKCD here. In this case, I think https://xkcd.com/2030/ is on point. The more you know about software engineering, the more you'll realise the entire thing is held together with bailing wire, duct tape, luck, and an intern trying to live edit the production database to fix the data errors before anyone notices.)

Third, and very much related to the last two points, consider the scale. Your car's gas tank, or your building;s sprinkler tank, are vulnerable to various attacks, but it's not vulnerable to being attacked remotely and untraceably by almost anyone on earth via a number of low skill attacks. And of course, software also can yield larger rewards. If the local corner store has a dodgy lock, maybe you could break into it (at significant risk to yourself!) and steal some cash from the till. If you can compromise the head office network of a major retailer, you could steal millions of dollars.

Edit: Also, I'm aware of a nationwide outage for a pizza chain caused by a phonebook. There was an internal webpage that some stores looked at occasionally to show stock levels or something similar. It was quite a slow/expensive page to load, but because it was loaded quite rarely, and only by a small number of internal users, it didn't have a lot of cacheing or rate limiting on it. Someone in one store shifted something on their desk, then walked off. This caused a phonebook to shift, and depressed their F5 key. That caused their browser to start refreshing this page very, very rapidly - multiple times per second. The load from this actually overloaded the central servers, and the entire system went down, stopping orders from being placed or printing out. So it might seem silly to say "hey, what happens when I do this thing I shouldn't do", but actually, over time, all sorts of things that "shouldn't happen" will happen for some reason or other. If the result is that every store of a nation-wide chain goes offline, that is....not great. And software is just way more prone to these sorts of things than others. If you tell me there's a vulnerability that lets people easily open the door of any hotel room at a large chain, I'll instantly bet you $20 it involves smart locks, NOT traditional mechanical keyed locks. (And indeed, that's happened more than once, and it's always been a smart lock to my knowledge.)

Post reply on HN