|
Suspicious Dish posted:Here's a dumb piece of garbage: gcc 9.0 Oh, I can understand how they would introduce that bug, since the empty string is indeed a zero initializer when it's used to initialize a char array. Sortof a representation bug if that kind of thing is still relevant at the layer which is trying to optimize code generation for initialization, though. EDIT: oh, hah, it's in their template-matching code. That's all a giant hack in Clang, too.
|
# ? Jun 21, 2019 05:29 |
|
|
# ? Jun 8, 2024 06:21 |
|
The listed example doesn't use templates though...
|
# ? Jun 21, 2019 08:33 |
|
ESR is free to declare that "[gif2png] is not expected to be able to deal with arbitrarily broken input", but the practical meaning of that is "gif2png is not intended to be safe to use on files from untrusted sources". And the project page does not warn users of that anywhere. In fact it heavily implies that it is fine to use it on untrusted sources from the internet:quote:This distribution also supplies web2png, a Python front end for gif2png which automagically converts entire web hierarchies (the graphics files themselves and references to them in web pages).
|
# ? Jun 21, 2019 10:20 |
|
zergstain posted:I tried writing a SIGSEGV handler once. That was a long time ago when I was much newer to programming, and I was just playing with stuff, so it's not in the wild anywhere. If I remember, I thought I could "uncrash" the program. Never got anywhere beyond an infinite SIGSEGV loop, and gave up on the idea shortly. It is possible, in certain cases and with careful preparation, to recover from a SEGV and continue. There's a GNU library for doing this.
|
# ? Jun 21, 2019 10:46 |
|
What's even the rationale for esr's gif2png when netpbm and imagemagick exist?
|
# ? Jun 21, 2019 13:44 |
|
JavaScript code:
|
# ? Jun 21, 2019 14:28 |
|
fritz posted:What's even the rationale for esr's gif2png when netpbm and imagemagick exist? megalodong posted:of course where would the internet be without raymond? nowhere, that's where!
|
# ? Jun 21, 2019 14:47 |
|
iospace posted:Unrelated I've gotten a BIOS to segfault once. That was fun. Wait, you mean bios in the efi sense right? Or ....
|
# ? Jun 21, 2019 14:50 |
|
dougdrums posted:Wait, you mean bios in the efi sense right? Or .... I've done BIOS development.
|
# ? Jun 21, 2019 14:53 |
|
qntm posted:
Eli, Eli, lema sabachthani?
|
# ? Jun 21, 2019 14:56 |
|
iospace posted:I've done BIOS development.
|
# ? Jun 21, 2019 15:00 |
|
dougdrums posted:How do you produce a segfault in real mode though? There were a couple ways, not sure how much of it was involving proprietary code but you could do it pretty much the same way you introduce a segfault in other situations: try to access poo poo you have no access to.
|
# ? Jun 21, 2019 15:04 |
|
Trying to read the result of underflowing to a memory address beyond what's installed?
|
# ? Jun 21, 2019 15:14 |
|
qntm posted:
PASCAL programmer spotted? Although PASCAL didn't distinguish strict equality from equality IIRC.
|
# ? Jun 21, 2019 15:35 |
|
Arsenic Lupin posted:Depends on the old people. A friend of mine once said, "Fred doesn't have ten years of experience in Smalltalk, he has one year ten times." There exist people who haven't met a new idea they liked since 1990. There also exist people who keep growing and changing. http://thecodelesscode.com/case/100 posted:A novice asked master Banzen: “What separates the monk from the master?”
|
# ? Jun 21, 2019 17:03 |
|
fritz posted:What's even the rationale for esr's gif2png when netpbm and imagemagick exist? So that esr can pretend he's actually made something important.
|
# ? Jun 21, 2019 17:05 |
|
ToxicFrog posted:Banzen shook his head sadly. “Ten mistakes, a thousand times each.” AKA Stop. loving. Using. strcpy.
|
# ? Jun 21, 2019 17:49 |
|
Arsenic Lupin posted:AKA Stop. loving. Using. strcpy. ok *uses strncpy, badly*
|
# ? Jun 21, 2019 19:28 |
|
Given that it is not possible to use strncpy well, you are doing ok
|
# ? Jun 21, 2019 19:53 |
|
taqueso posted:It means that for some input, instead of saying "hey thats bad input" it just crashes. I've seen an escalation to a developer and the retort was "it was not in the requirements to not crash." Try working with finance land for abit, it's a different world. You have to write to spec or things will impressively fall apart. It's not like Apple doesn't fall into the same poo poo pile either, MacOS X Server was built on the premise of "You must follow the instructions and do nothing else". Like the disk management tool was very powerful but would crash and fail spectacularly on configurations outside of what was in the documentation.
|
# ? Jun 21, 2019 20:43 |
|
A tool where you have to follow the instructions or things break can be a reasonable choice when a training session for every user the tool will ever have is dramatically cheaper than making the tool better. It is not even slightly reasonable when the tool exists to slurp in untrusted input from the internet.
|
# ? Jun 21, 2019 23:46 |
|
I'm still in awe of "meaningless fuzzer bugs"
|
# ? Jun 22, 2019 01:06 |
|
JawnV6 posted:I'm still in awe of "meaningless fuzzer bugs" Sometimes you control all the input
|
# ? Jun 22, 2019 01:15 |
|
Even if you control all the input, you are just waiting for the "if the parser is liberal in accepting incorrect input, someone will end up relying on that behavior" (sorry quote is from memory and mangled)
|
# ? Jun 22, 2019 03:37 |
|
iospace posted:There were a couple ways, not sure how much of it was involving proprietary code but you could do it pretty much the same way you introduce a segfault in other situations: try to access poo poo you have no access to. in x86 real mode don't you have access to everything because there is no MMU/the MMU is disabled? Do you mean bus error (CPU tried to do the access and no other chip acknowledged a read/write to that address)?
|
# ? Jun 22, 2019 03:52 |
|
x86 real mode actually uses segments, so I assume a "segmentation fault" in that context is far more literal than what you get in protected mode.
|
# ? Jun 22, 2019 04:19 |
|
zergstain posted:I tried writing a SIGSEGV handler once. That was a long time ago when I was much newer to programming, and I was just playing with stuff, so it's not in the wild anywhere. If I remember, I thought I could "uncrash" the program. Never got anywhere beyond an infinite SIGSEGV loop, and gave up on the idea shortly. Same, and then a while after I gave up everything on my system stopped working and I realized that the segfault loop had continued in the background somehow and a related log file had filled up my disk.
|
# ? Jun 22, 2019 04:46 |
|
Hey, folks, what's your opinion on the following pair of articles? I never did frontend, so I'm more clueless than usual. https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://hackernoon.com/part-2-how-to-stop-me-harvesting-credit-card-numbers-and-passwords-from-your-site-844f739659b9
|
# ? Jun 22, 2019 05:35 |
|
Arsenic Lupin posted:Hey, folks, what's your opinion on the following pair of articles? I never did frontend, so I'm more clueless than usual. There are a great deal of real concerns surrounding the use of 3rd party code no matter what. Most people do not check the code they are implementing and subsequently running on their server. The hope is that at least somebody out there is but there really are so many libraries that are used in so many places, it would be difficult to keep up with it. Libraries are often dependencies of dependencies of dependencies and are always the latest patch version which isn't necessarily "only" a patch. This isn't an issue with frontend either, quite probably much more damage could be done on the backend. Npm is fundamentally broken. And at the exact same time radically overused.
|
# ? Jun 22, 2019 05:56 |
|
https://medium.com/intrinsic/compromised-npm-package-event-stream-d47d08605502 it's happened before quote:This package receives over 1.5mm weekly downloads and is depended on by nearly 1,600 other packages
|
# ? Jun 22, 2019 06:04 |
|
Arsenic Lupin posted:Hey, folks, what's your opinion on the following pair of articles? I never did frontend, so I'm more clueless than usual. It's a problem with code everywhere, web frontend or not. However, frontend does have a fetishization of using third-party code for every single thing possible. My PC is running bajillions of lines of code in I haven't audited and probably no one has audited well. The applications I have installed are using third-party libraries that I'm sure no one audited when they decided to use them. However, the real mystery is taken from the second article. mystery posted:When the user has filled in that form (filled out that form? — why are opposites the same!?)
|
# ? Jun 22, 2019 19:10 |
|
Thermopyle posted:It's a problem with code everywhere, web frontend or not. However, frontend does have a fetishization of using third-party code for every single thing possible. Unaudited third party dependencies exist anywhere, yes, but only in the javascript world is it standard practice to pull in literally hundreds of distinct libraries before you write a single line of your own code. The attack surface is far, far larger.
|
# ? Jun 23, 2019 08:23 |
|
Not to mention generally delivering the code to client browsers instead of it only being a server dep.
|
# ? Jun 23, 2019 12:48 |
|
Soricidus posted:Unaudited third party dependencies exist anywhere, yes, but only in the javascript world is it standard practice to pull in literally hundreds of distinct libraries before you write a single line of your own code. The attack surface is far, far larger. Other developers do that by using Web frameworks or GUI frameworks or whatever. But also, any developer is doing all of their work on top of at least a kernel and programming language. The only difference between those dependencies and library dependencies is what you choose to call them. Of all the reasons to hate JavaScript, the microlibrary thing is not one of them. The only reason not to do that is because of implementation details. It's a wonderfully good idea overall. necrotic posted:Not to mention generally delivering the code to client browsers instead of it only being a server dep. After the code is compiled, it makes literally zero difference if the function was defined in a separate package or not. Modern compilers also shake out the unused code. This is admittedly a huge problem when people just ship tens of separate JS library files, but there are dumb developers everywhere.
|
# ? Jun 23, 2019 16:13 |
|
You appear to be missing the point. The problem we’re talking about is accountability. Sure, the number of lines of code may be similar, but in a traditional monolithic library case those lines are collectively owned by a large group, and no one individual can easily subvert them. In the npm case, you have hundreds of separate codebases each of which may be maintained by a different single person, and thus the risk that one of those dependencies will silently be replaced with something malicious becomes worth worrying about. You’re trusting the library developers a lot more, and furthermore, since the dependency graph is so much deeper, you probably don’t even know who you’re trusting.
|
# ? Jun 23, 2019 16:25 |
|
Soricidus posted:You appear to be missing the point. Good point, but I still don't see how that's different from trusting the kernel or browser or even the algorithms. Plus, if you keep complaining about it, JavaScript people are just going to solve the problem by using WebAssembly in a sandbox instead, and you'll be wishing we were back to now.
|
# ? Jun 23, 2019 16:29 |
|
xtal posted:Good point, but I still don't see how that's different from trusting the kernel or browser or even the algorithms. The kernel and browser will generally be large projects that have established procedures around changes being made, and have a lot of attention paid to them. When you compare that to some dipshit's NPM package (one of thousands, and which may be quite trivial while it remains honest) there is a clear qualitative difference in terms of how much attention is likely to be paid. As much as JavaScript sucks, the issue isn't whether it's JS or WebAssembly, it's how the bits of code you pull in are decided and who has a role in deciding what's in them.
|
# ? Jun 23, 2019 16:51 |
|
xtal posted:Plus, if you keep complaining about it, JavaScript people are just going to solve the problem by using WebAssembly in a sandbox instead, and you'll be wishing we were back to now. That’s completely orthogonal though. If all those little libraries are compiled down to wasm the problem will still exist. It’s really the sheer number of unique dependencies that are developed by a single person abetted by the frequent lack of actual reviews of the code that permeates the entire system. There’s a lot of code in the kernel; there’s also a lot of people in the kernel projects and established systems for reviewing and testing that code. It’s not perfect but it’s a lot better than somebody way far down in your dependency tree blindly adding a dependency they haven’t looked at that is now in your shipping code.
|
# ? Jun 23, 2019 16:56 |
|
And which can be silently swapped out later with malicious code once the author gets an offer for it
|
# ? Jun 23, 2019 17:03 |
|
|
# ? Jun 8, 2024 06:21 |
|
I think the idea, whether it exists in practice or not, is that those little libraries have more code review and cover more edge cases than the solution you'd write yourself, because they are open source and relied on by all these other projects. In a utopian future, we would all have a single left-pad or is-odd implementation that we decided was optimal as a community.
|
# ? Jun 23, 2019 17:06 |