It does indeed feel there is a gaping hole in our software stack as these buffer overflows are only increasing in rapidity. It is time we take a serious look at the epidemic of exploits in C land, and begin to implement real solutions; they are out there.
It’s hard to deny that easy access to stack, especially unpriveleged access, plays a serious role in creating computer crime. How many buffer overflows happen in languages with access checks on stacks? How many buffer overflows are discovered in the Ada each year? None. How many in Haskell? None. How many in Java? None. The list could go on. And yet, mass exploitation in the C-land continue to increase. There is certainly a correlation. But there are other important causes at play as well: the language is an ill-designed clusterfuck of hacks upon hacks.
Of course, mass buffer overflows are only one indication of the security nightmare that plagues the language — the whole language is built on unsafe and insecure code. In the C-land, memory rules are much more lax than that of other popular languages, on par with the assembly and lacking even basic safety features: unless explictly requested by the programmer.
These are a only a few of the indicators of what may feed into the hopelessness and despair that causes so much distrust in C and its derivatives. The bugs cost real money and real work-hours to be wasted on correcting and debugging the garbage that was compiled by compilers which don't value anything but speed and memory use..
Name:
Anonymous2016-08-18 6:38
Its 2016, people still use C rationale excuse to explain away deficiencies in C: and C committee is stuck in the past. https://www.lysator.liu.se/c/rat/a.html
Name:
sega2016-08-18 6:51
How many buffer overflows are discovered in the Ada each year?
Btw, ignoring the obvious troll, if you had any clue about the internal workings of a core switch, you couldn't name one proglang in which to implement code for it besides C. Linespeed!
I think people's minds are damaged by thinking about a layer of C between their program and the hardware even if they're not writing it in C.
Knowing about the low level is important, but you should be thinking about the CPU architecture instead of C.
Even decompiling programs is more difficult when you use C or C-like languages.
Name:
Anonymous2016-08-18 19:05
>>3 no you fucking moron. > durr you can only write it in C this article proves you cannot write it in C even if you wanted to
Name:
Anonymous2016-08-18 20:23
I don't like how people always spout that C is "close to the hardware". You can't even do a fucking arithmetic right shift in C, let alone get access any of the cpu caches or cores. C is only "close to the hardware" if you're programming for a PDP-11.
Only the corporate tyranny wants to ban "insecure" things. Because then the masses cannot revolt. Imagine a world in which everything is "perfectly secure". You'd be living in a prison. Some big faceless entity will have decided everything about what you can and cannot do. If you don't like how something works? Sorry, that "perfect security" means you can't change it. It doesn't even have to be DRM. They'll force adverts into your brain and it'll be illegal and impossible to get away from it. This is like 1984, but much worse.
So the fact that things get hacked regularly is good. It means that there is still freedom. They don't call them "jailbreaks" for nothing...
If you are a proponent of "safer" languages you are basically advocating for "guilty until proven innocent" and want to turn programmers into mindless drones by restraining them to do exactly what you want. FUCK THAT SHIT.
"Insecurity is freedom." "Those who give up freedom for security deserve neither."
Name:
Anonymous2016-08-19 10:41
>>1 The C programming language does not offer any kind of easy access to any stack. The problem lies in your implementation and your inability to chose ``safe'' compilers. If you made use of a compiler for Haskell or Java that allowed for access to the stack then you would have the exact same problem.
>>17 hey Cudder, I see where you're comming from and I like that old-school hacker mindset but there's just one problem with it: the landscape has changed. in the 90s/early 00s, insecure code provided countless relatively harmless lulz but as time went on, it became abused by NSA, other governments, corporate advertisers, common thieves and other people you don't want on your computer.
the solution to jailbreaking isn't more buffer overflows. it's more open-by-design devices. the same goes for crypto: bad crypto might be cool when you're breaking a DRM but it's less cool when someone can spy on your communications. security is a technical issue, openness is a cultural one.
I think we can have both secure software which gives us privacy and the ability to install, modify and hack anything we want on our devices. hell, given the stupidity of webdev monkeys means we can be able to not only have those things but also to have oldschool hacker lulz while the critical (not web-based) systems will be secure.
The C programming language does not offer any kind of easy access to any stack.
..says the nigger who has never C enough. I guess taking the address of a stack-allocated item is just some fantasy to you.
>>17 Go fuck yourself with a shotgun, you fucking ignorant malignancy. You don't know what the fuck you're talking about with the shit you drool on about "insecure" things. You don't even warrant a response beginning to describe the myriad places where you go into fuck-off land.
I guess taking the address of a stack-allocated item is just some fantasy to you.
While your compiler might allow you to do that the C standard says nothing about it.
I far that you misunderstood my post due to your inability to think out of the box.
Go fuck yourself with a shotgun, you fucking ignorant malignancy. You don't know what the fuck you're talking about with the shit you drool on about "insecure" things. You don't even warrant a response beginning to describe the myriad places where you go into fuck-off land. Just die already, you worthless piece of shit.
This is the first and the last time I warn you: Don't you fucking bully Cudder or I will come to your house and rape you using a snake with retarded looking eyes.
C is only "close to the hardware" if you're programming for a PDP-11.
How do you access the PDP-11's flags from C? Multi-precision arithmetic is pretty simple on the PDP-11.
Name:
Anonymous2016-08-19 16:55
>>12 Now do it on a way that doesn't depend on the compiler. Even JAVA has >> and >>>.
Name:
Anonymous2016-08-19 16:56
They are `close to the machine' in that the abstractions they introduce are readily grounded in the concrete data types and operations supplied by conventional computers, and they rely on library routines for input-output and other interactions with an operating system. https://www.bell-labs.com/usr/dmr/www/chist.html
Name:
Anonymous2016-08-19 16:57
>>24 Wow, it looks like I was wrong. C was trash from the very beginning.
Now do it on a way that doesn't depend on the compiler.
I guess you are right. I could now try to create a portable arith shift using unions (signed and unsigned types have the same size and 2s complement can be emulated using unsigned types only in C) and other binary ops but what's the point? The behaviour is the same as signed division. Arithmetic shifting has always been an optimization for divisions and most of the time you want binary shifting anyway. If you could give me an example of when you actually need arith. shifts (and not premature optimizations of divs), I would be thankful. I would be more concerned that C doesn't have native binary rotations but then again there are portable workarounds to this.
Even JAVA has >> and >>>.
Yeah, and no unsigned types, which would have prevented the stupid additional operator here.
Name:
Anonymous2016-08-19 18:23
>>28 "C is close to the hardware." "No it isn't, C doesn't even provide this simple binary operation supported by every available architecture since the beginning of time." "Why would you want that."
Nice misquoting me. I never even said anything remotely similar.
"Why would you want that." I see what you mean but there's other stuff you can do with it as well
Again, providing a reasonable use-case for arith shifts in HLLs (anything above assembler) would be nice. But since you want arith shifts in C (and possibly other HLLs, too), why not also add all these weird x86 ASCII/BCD ops, too? Oh yeah right: because you don't need them. Prove me wrong or shut it. C is confusing enough, adding even more undefined behaviour in the form of weird binary ops isn't going to help.
Name:
Anonymous2016-08-19 23:39
None of you fucknuggets who are saying C is secure, or that asm-level operations shouldn't be exposed are worthy of gracing even a shithole such as /prog/. Y'all need some McCarthy in yo life.
>>33 And exactly none of said fucknuggets were around for the 8-bit home computer era where assembly language was necessary, and taught you how to use bit tricks and find ways to slam into code to save space. A bunch of uneducated millenial nigger hipsters in this thread, I tells ya.
Name:
Anonymous2016-08-20 2:36
>>35 This. Start low-level. Most /prog/rammers today can't even sort an array if their language don't have .sort() included.
Name:
Anonymous2016-08-20 10:30
Learn you a Commodore 64 for great good, so you can control your hardware again.
Name:
Anonymous2016-08-20 10:31
: inc $d020 jmp :-
Name:
Anonymous2016-08-23 3:01
If you want to depose C you have to provide a replacement that gives you just as much power.
>>41 is it really a C replacement? when I started learning lithp, I asked here for help with basic networking tasks and I was told to just use FFI and write wrappers over C libs. I like the language but how can it replace C if it needs C libraries to do practical stuff.
Name:
Anonymous2016-08-23 10:04
>>43 That has nothing to do with the language, it has 100% to do with how much time people in smaller communities spend reimplementing wheels from other languages.
Plus, you must have started learning lithp 20 years ago, because networking is well supported in every major Common Lisp implementation.
Name:
Anonymous2016-08-23 10:05
(this space left behaving undefinedly)
Name:
Anonymous2016-08-23 10:31
>>43 then how do you find MX records for a given domain name? I've asked on /prog/ some time ago and the best answers I got were about FFI (there was also some bullshit about how network-related stuff is for codemonkeys and a true lithper just doesn't do that)
Name:
Anonymous2016-08-23 12:12
>>45 I'd place the "basic" in "basic networking task" more along the lines of "common case", instead of lower level. That's something that isn't on many people's radar, hence isn't on many people's radar for "let's replicate functionality for X in my language".
And that has nothing to do with Lisp, really. How many non-topN languages expose DNS calls? This is explicitly a "call the OS for this particular thing" functionality, not something built on other commonly interfaced tools (memory management, threads, function calls, socket & file I/O).
Nice misquoting me. I never even said anything remotely similar.
So you agree with me? I guess we're done here.
Name:
Anonymous2016-08-23 19:41
>>50 Well, it could certainly be closer to hardware. But you can also think about it this way: it is closer(or rather: can be closer to HW but doesn't have to be -- isn't there this 'safe' C that's like 50x slower than 'normal' C?!? Anyway...) to HW than other langs, including a lot of these that want to be C replacements. So, looking from ASM, it's somewhat far from HW. Looking from JS, it's close to HW. I'm obviously a C nerd but I also miss overflow checks and the likes from time to time. The point is that C isn't perfect but instead of actually trying to fix it, hipsters try to fix it by replacing it with {lang-of-the-day}.
Name:
Anonymous2016-08-23 20:46
>>51 The only things ``close to hardware'' about C are the ability to read and write memory at an arbitrary address (like Ada, PL/I, GHC Haskell, and several dialects of Pascal and BASIC) and having hardware-efficient (on binary untagged architectures with flat address spaces) primitive types (in that sense, C is as ``close to hardware'' as JavaScript and Haskell).
Reading and writing memory at an arbitrary address is implementation-defined behavior in C.
Name:
Anonymous2016-08-23 21:23
>>51 Well ideally this would be the job of the Standard, but given the track record things are looking very depressing. - No way to zero a buffer until C11 (http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html) - Still no threading model (Maybe this decade?) - Still no module system (Manually prefixing all your variables? Even the Java people are laughing at you.)
Name:
Anonymous2016-08-23 22:23
>>52 I don't know jack about Haskell but I'm pretty sure you can't convert an expression in JS to native instructions as straightforward as in C, especially when you want to have it optimized. Also, try to run such JS expressions on an 8-Bit Atmel. I'll be waiting here (literally).
Reading and writing memory at an arbitrary address is implementation-defined behavior in C.
It's usually pointless and dangerous in any language and in the end up to the OS (even CPU nowadays: NX Bit etc.) if it's legally possible at all.
but I'm pretty sure you can't convert an expression in JS to native instructions as straightforward as in C, especially when you want to have it optimized.
What in the fuck do you think the transparent optimizing JIT compiler is, you niggercunt? You don't have to do a god damned thing to have JS convert to optimized native instructions. Can't get more "straightforward" than that.
and I even hate JS, but your post is just bullshit
I don't know jack about Haskell but I'm pretty sure you can't convert an expression in JS to native instructions as straightforward as in C, especially when you want to have it optimized. Also, try to run such JS expressions on an 8-Bit Atmel. I'll be waiting here (literally).
That's really up to the implementation. The reason JS is considered low performance is because it's canonical implementation is a interpreter, which are generally slow. But there's no reason why you couldn't have a compiler that takes Javascript code, and generates efficient machine code from it. After all, both JS and C have a lot of constructs that are semantically similar - a for loop in JS does the same thing as a for loop in C, so there's no reason why it should be such an issue. Javascript on embedded systems basically doesn't exist, but that's mainly because C is already adequate in that role - there's no need to create a highly optimizing Javascript compiler for such environments, since JS doesn't provide enough of an advantage over C. It could be done, there's just no incentive for it.
Name:
Anonymous2016-08-24 1:30
It would be a bit more difficult to compile and optimise JS due to stuff like dynamic typing or eval. However it would not be impossible or anything like that.
Name:
Anonymous2016-08-24 1:39
>>56 >>57 Consider for example some of the examples in this article: http://www.html5rocks.com/en/tutorials/speed/v8/ JS requires that numbers be 64 bit floats (by standard). In order to improve performance on real life hardware, the V8 engine (arguably one of the most sophisticated JS engines) uses tagging and dynamic dispatch mechanisms at runtime to speed up the execution. C doesn't need this because the programmer can say unsigned short when s/he knows that s/he doesn't need more at this point. Type is resolved at compile time instead of execution time and the program runs faster because the programmer was able to describe more precisely what s/he wants from the machine. Unless you compare C vs JS on a machine that only offers 64-bit-float-registers (because thats what JS runs on, although this machine probably doesn't exist in reality), C will most likely be faster because it maps better to real hardware, making it 'closer to HW'.
Name:
Anonymous2016-08-24 2:46
>>59 You do realize that you linked to a 4 year old page on a totally shit site, right? You don't even know what the fuck the compiler is doing, and what situations it actually does compile down to integer register machine code ops, right? Fuck off, you ignorant cunt.
C doesn't need this because the programmer can say unsigned short when s/he knows that s/he doesn't need more at this point.
Being able to use data types of different sizes is typical for statically typed languages. There's nothing special about C here. For example, there's Word16 in Haskell.
C will most likely be faster because it maps better to real hardware, making it 'closer to HW'.
How does C map better to the hardware? It doesn't let me choose the layout of my data structures. That kind of thing is important when you want to interface with memory-mapped hardware devices. Most things in C that appear to be close to the hardware are undefined behavior.
Name:
Anonymous2016-08-24 4:59
>>57 no javascript implementations would be nearly as fast as C if this were true, considering the massive amount of work people have put into it
Name:
Anonymous2016-08-24 5:34
>>62 C is only fast because you take the hit in compile time (often 30 seconds for even small programs), that's the cost of optimization. If Javascript was distributed as binary files, you could get away with compiling it once, but since it's distributed as source code, having to wait half a minute for it to compile before you can run it is unacceptable. So instead, implementations are interpreters or non-optimizing JIT compilers, which produce code that executes slower, but overall it's faster than C source once you factor in the compilation/optimization overhead.
Name:
Anonymous2016-08-24 7:43
JavaShit
When [] == "", you must have a fuckhuge pile of machinery constantly running in all cases. This is why JavaShit is slow and no one in computer science takes it seriously.
implementations are interpreters or non-optimizing JIT compilers
that's completely false though. all major js implements use combinations of interpreters and/or compilers but all of them include an optimizing JIT compiler.
Name:
Anonymous2016-08-24 11:46
and nobody writes JS interpreters anymore, since it's easy to grab the existing mature JIT engines. Unless you're on some fuckoff weird platform it doesn't support.
Name:
Anonymous2016-08-24 13:24
When [] == "", you must have a fuckhuge pile of machinery constantly running in all cases
The mystery disappears when you see its comparing string vs non-string, the first thing it converts [] to a string ([]).toString()=="", both now simplify to ""==""
Name:
Anonymous2016-08-24 13:52
>>63 Again: JS may require multiple dispatch even for something as simple as an addition, while C permits the compiler to just emit an addl. JS describes a specific abstract machine; C describes a very unspecific abstract machine that 'just so happens' to map well to a lot of real hardware.
Name:
Anonymous2016-08-24 13:58
>>68 add. But why the fuck are we discussing JS anyway? Most people can see from far that it's unsuitable for most of the jobs C was originally designed for.
And if Haskell can be so low-level as you (or others) describe it then write me some low-level application and prove it worthy as a C replacement. Hint (concerning both JS and Haskell): if I need to install a 400MB runtime in order to run your application you've already lost.
Name:
Anonymous2016-08-24 18:04
>>65 A JIT compiler can't optimize to the degree a regular one does, since the speed of compilation is important.
Name:
Anonymous2016-08-24 20:26
>>68 Bullshit. The JS compiler can emit an unchecked addl as well, if it's adding integers. Fucking ignorant retards.
Name:
Anonymous2016-08-24 20:54
>>70 Speed of optimized compilation is irrelevant if done threaded. Fast path detection and heuristic collection isn't fast anyway.
Name:
Anonymous2016-08-24 21:07
>>72 Threading can only do so much when for execution speed. Each processor core can only run one thread at a time, beyond that limit, additional gains in speed only occur if one of the active thread must wait for some reason, allowing another thread to get some work done in the meantime.
Name:
Anonymous2016-08-25 1:57
>>73 Did you even read what I said? It doesn't matter how slow optimization is, because it can be threaded out.
Name:
Anonymous2016-08-25 2:01
>>74 Threading isn't magic. A CPU can only work so fast.
Name:
Anonymous2016-08-25 2:04
>>75 Kill yourself, you backwards fuckhead. But I think your flying off into random tangents will send you into orbit anyway. Enjoy asphyxiation in a vacuum, idiot.
Computers have been fast enough for years, it's time we start demanding security.
I used to have a computer that took 1m30s to boot, now it only takes 10s, but it's still buggy and insecure. I'd rather have a computer that once again takes 1m to boot, but that I know cannot be subverted by state actors.
We need languages in which strict security is a feature. C is way too liberal.
oh and >>17, you have gone off the deep end. 'Insecurity is freedom' ?? You have been smoking shit. >>19 is right on the money. Besides, I don't believe you ever really "hacked" anything, poser piece of shit.
Name:
Anonymous2016-08-25 15:31
>>80 The only reason we still have jailbreaks for phones, cracks for games and torrents for tv shows is because of C. You'd rather have it so all the vendors could team up and lock down all of their devices in the name of "security"? Make it so that it's impossible to find a device with an unlocked bootloader on the market?
Name:
Anonymous2016-08-25 18:09
>>17 vulnerabilities exist even if you are using a "safe" language/platform
>>81 This is actually what I want. This way, we can actually support companies and initiatives the produce hardware that respect the users' freedom.
Name:
Anonymous2016-08-26 7:33
>>81 You can still crack software, and capture tv even if their designs were bug free, because if you can run or play something, you can modify it to do anything you want (for software cracks), or decrypt the transmission (because your player has to be able to play it). An absolutely secure bootloader only means that modifying it would be prohibitively expensive as it would require tools that are currently not yet available cheaply, however you could run anything that runs on that hard on more Free hardware as long as its compatible - that's how emulation works, and given the right hardware tools there's nothing preventing anyone from extracting any hardware secrets or keys, thus breaking down their entire chain of trust.
Secure software design would not endanger cracks or capturing tv shows, but it might make them a lot more expensive. It would also make all those consoles and smartphones worth throwing in the trash because you wouldn't be able to open them up, as the hardware only obeys their makers, but you could run anything that runs on them on more open hardware if you could extract their secrets.
>>84 The pro-DRM bastards want control over your brain. They want to feed you adverts and manipulate your mind directly. They would make you experience sensations of physical pain for even thinking of anything subversive if they could. Direct neural interface? DO NOT WANT!
At the end of the day, all you're trying to do is build safe abstractions upon an unsafe machine (in this case a computer with things like pointers, unseparated address spaces, overflows and whatnot). The point is that: A. a lot of computing environments (CEs) (a HLL in this case) use C as a bottom layer and it could be argued that since the CE internally uses C, then the CE is similarly insecure OR B. that you don't need the HLL at all, since you can write safe abstractions in C itself
B. that you don't need the HLL at all, since you can write safe abstractions in C itself
You don't need C at all because x86 assembly has better error handling, better primitives (e.g. SIMD), and better macros. I'm not even joking. It really is better.
Are x86 macros even portable between different assemblers?
Name:
Anonymous2016-09-06 2:07
>>106 No, they're assembler specific. So with GNU Assembler, the macros are actually portable across the different assembly languages. Same macros for x86 and arm for example.
Name:
Anonymous2016-09-06 7:47
>>107 Asm by itself is not portable so the macros don't change anything. Also, if you need asm macros FASM is far superior to GAS.
All this security is going to turn society into a bureaucratic, authoritarian, dystopian prison. We're basically locking ourselves up, and these masses of sheeple are blindly charging full speed into it without ever questioning what they're losing. As long as they feel safe and secure they'll sacrifice anything.
It’s hard to deny that being able to think, plays a serious role in creating computer crime.
FTFY.
"If freedom is outlawed, only outlaws will have freedom."
"The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants."
Letting C into your computer is like letting terrorists into your country. C ``empowers'' real terrorists to damage physical equipment, like Stuxnet, create viruses and ransomware, and spy on people. They might be able to do it without C, but their job would be a lot harder.
The governments use exploited C programs as an excuse for why they need more laws, bigger agencies, hardware backdoors, and all of this ``bureaucratic, authoritarian, dystopian'' bullshit.
Name:
Anonymous2017-05-02 18:00
Cee and Sepples will prevent skynet from being functional, debugging Sepples code cannot be practically automated.
>>119 Why should the mere act of connecting a computer to the Internet allow anyone to spy on you? Does the television let them watch you? Can they hack your furnace and burn down your house? Eliminating C would also make backdoors easier to find, but they don't want that. Internet of Things? No, C of Things. The Internet is fine. C is the problem.
>>120 7/10 C programs are exploitable? Try 10/10. You used to say C wasn't a problem and now you're saying it's good that C's a problem. Anything to defend the Mossad's greatest ally. Stuxnet wouldn't be possible without C.
