Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Data Breach Flaw Found In Gnome-terminal, Xfce Terminal and Terminator

timothy posted more than 2 years ago | from the so-it-can-be-fixed-now dept.

GNOME 184

suso writes "A design flaw in the VTE library was published this week. The VTE library provides the terminal widget and manages the scrollback buffer in many popular terminal emulators including gnome-terminal, xfce4-terminal, terminator and guake. Due to this flaw, your scrollback buffer ends up on your /tmp filesystem over time and can be viewed by anyone who gets ahold of your hard drive. Including data passed back through an SSH connection. A demonstration video was also made to make the problem more obvious. Anyone using these terminals or others based on libVTE should be aware of this issue as it even writes data passed back through an SSH connection to your local disk. Instructions are also included for how to properly deal with the leaked data on your hard drive. You are either encouraged to switch terminals and/or start using tmpfs for your /tmp partition until the library is fixed."

cancel ×

184 comments

Sorry! There are no comments related to the filter you selected.

Skynet (5, Funny)

Talderas (1212466) | more than 2 years ago | (#39288559)

We have a means to strike back at Skynet using this breach in the Terminator systems!

hell ya open source rules (-1)

Anonymous Coward | more than 2 years ago | (#39288571)

not like those apple assholes who make shit that works

Re:hell ya open source rules (-1)

Anonymous Coward | more than 2 years ago | (#39288715)

You're obviously being sarcastic or haven't ever used the trainwreck that is XCode.

Re:hell ya open source rules (0, Offtopic)

Anonymous Coward | more than 2 years ago | (#39288767)

I would have responded sooner but this beachball would NOT go away.

Re:hell ya open source rules (0)

Mikkeles (698461) | more than 2 years ago | (#39288853)

You got that half right.

first... (0)

Anonymous Coward | more than 2 years ago | (#39288595)

...to have my command history stolen!

Overblown (4, Insightful)

AliasMarlowe (1042386) | more than 2 years ago | (#39289345)

...to have my command history stolen!

That would be in your .bash_history file (or whatever you name it locally).

Really, this is way overblown by calling it a "data breach": it's not as if your data is compromised to a remote attacker. It requires that somebody else has your disk. As we all know, if your hardware is stolen/confiscated/impounded/seized/whatever, only encryption can keep your data safe. Apparently, even that can be circumvented by legal compulsion.

Re:Overblown (2)

masternerdguy (2468142) | more than 2 years ago | (#39289565)

The real problem is disk space usage. Eventually that file may grow to millions of terrabytes. This is the memory leak from hell.

Re:Overblown (5, Informative)

behdad (320171) | more than 2 years ago | (#39290913)

That's misinformed. Vte creates files in /tmp, and immediately delete them. So, the space will be reclaimed as soon as the terminal tab in question is closed. I know this is how it works, because that's how I wrote it.

Re:Overblown (0, Interesting)

Anonymous Coward | more than 2 years ago | (#39291257)

Funny, Behdad, I thought you weren't going to pay attention to this bug: https://bugzilla.gnome.org/show_bug.cgi?id=664611 [gnome.org]

I suppose once your name hit Slashdot you decided to change your tune, did you? Because it sure sounds like you're an arrogant prick from the thread you and Andre are trying to suppress.

Re:Overblown (-1)

Anonymous Coward | more than 2 years ago | (#39291595)

Ahh, so the fact that hard drives can't be secured 100% is a good excuse to do nothing to secure them at all? Congratulations, you'd make Behdad and the rest of the incompetents at GNOME proud with that logic. He's the bloody author of libVTE and he doesn't give a flying fuck about this wide-open hole in his own software either, he's too busy flapping the wide-open hole in the front of his head and boosting his own ego to get anything done.

GNOME care less about the users of their own software than they care about satisfying their personal vendettas and engaging in petty bickering, that's why this bug isn't being fixed. Behdad should be put back in his playpen where he belongs.

Where's the gun? (1)

Jawcracker Fuzz (1773468) | more than 2 years ago | (#39288671)

Shoot the VTE lib. Gimmie back my ASR 33.

How is this *really* a problem? (1)

Anonymous Coward | more than 2 years ago | (#39288737)

You have to be root (or the user who was running terminal in the first place) to see the scrollback data.

So, how is this different than all of the hack-tastic things that root can already do?

Re:How is this *really* a problem? (4, Informative)

jesseck (942036) | more than 2 years ago | (#39288935)

While the system is running, yes, you either need to be root or run an exploit which escalates your privileges so you can see the temp file. When the disk is removed from the system you don't need to be root to read the files. Nor would you need to be root if you booted from a LiveCD.

Re:How is this *really* a problem? (0)

Anonymous Coward | more than 2 years ago | (#39288989)

Unless /tmp was built using Luks...

This is a non-issue in those cases.

Console exploits (gaining access to the console of a running machine) are just the way things are...

Re:How is this *really* a problem? (0)

Anonymous Coward | more than 2 years ago | (#39289415)

Yeah, but the files are unlinked right after they're created so it's not as if they hanging around the filesystem. You'd still need use some form of data recovery to read the info from the disk after the machine is powered off. If someone has physical access to your drives, then you've got bigger problems than readable scrollback buffers.

Re:How is this *really* a problem? (2)

Cley Faye (1123605) | more than 2 years ago | (#39288951)

Surely you missed this part of the summary (you didn't even need to read the article):

and can be viewed by anyone who gets ahold of your hard drive

When dealing with real security needs, you might want to know if data only seen through SSH end up on your hard-drive.

Umm (3, Interesting)

Viol8 (599362) | more than 2 years ago | (#39289143)

If someone has physically stolen your computer then the thief being able to read old terminal sessions is the least of your worries.

Re:Umm (4, Insightful)

gzipped_tar (1151931) | more than 2 years ago | (#39289209)

The problem is your terminal history may include data from other hosts, decrypted. Therefore it's not just "your" worries.

Re:Umm (1)

X0563511 (793323) | more than 2 years ago | (#39289765)

LUKS. LUKS. LUKS.

Theft of a workstation or laptop drive should not threaten the rest of the network.

Re:Umm (-1)

Anonymous Coward | more than 2 years ago | (#39290251)

I assume you don't use SSH keys then.

Re:Umm (1)

xaoslaad (590527) | more than 2 years ago | (#39290749)

what does that have to do with the rising price of tea in china? If you use LUKS to encrypt the entire disk as is very easily doable in many distros (name one: Fedora/RHEL) then they aren't going to get your SSH keys either. They're on an encrypted file system. Good luck with that.

Re:Umm (1)

allo (1728082) | more than 2 years ago | (#39291087)

where is the problem with ssh-keys? mine has a looooooong password.

Re:Umm (0)

Anonymous Coward | more than 2 years ago | (#39290283)

The problem is your terminal history may include data from other hosts, decrypted. Therefore it's not just "your" worries.

So might your swap file, but most people don't encrypt that either. Seriously, you lose physical of your machine, you're screwed unless the entire disk is encrypted. I don't see what's so exciting about this story.

Re:Umm (5, Informative)

behdad (320171) | more than 2 years ago | (#39291429)

You have to read the bugzilla report carefully to see what this story is about. I'm the developer being [bf]lamed. I offered to find time on a weekend and fix the issue. But the reporter ignored my offer and went ahead to post this on as many places as it could. In the report, he masks that, and instead says I don't consider it a bug. The report is intentionally written misinformed IMO. Which makes me think the true story is that he wanted to get some publicity...

Re:Umm (-1)

Anonymous Coward | more than 2 years ago | (#39291891)

And yet you're not answering any of the criticism of your own behaviour in that very same bug, I see. Not a surprise really, being a GNOME developer you're bound to be immature, lacking in vision and any sort of responsibility to the people who use your code.

Publicity or not, there's a gaping hole in the security of libVTE and you're doing nothing about it. Better yet, you're using other developers to silence criticism of your behaviour on the official bug report. I think you're just trying to point the finger at him to take some of the heat off your own back, which is squarely where it belongs. If you're that incompetent that you can't fix the bug, then perhaps you should tell your friend Andre to stop doubling as one of GNOME's SS agents and work on a fix, you're obviously not interested in pushing one out yourself. Either that or you're simply incapable of it -- the problem's existed for years after all, perhaps all of your hand-waving is just to disguise the fact you're just not talented enough to fix it in the first place?

behdad@gnome.org If anyone else has a problem with this man-child's arrogance threatening the security of your own workstation or server, here's the new address for complaints.

Re:How is this *really* a problem? (2)

allo (1728082) | more than 2 years ago | (#39291067)

what about terminal-history in your swap-partition?

Re:How is this *really* a problem? (5, Informative)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#39288965)

If you are using a persistent /tmp, 'root' is anybody who mounts the HDD...

Now, if you want scrollback data to be persistent across reboots, you have to suck it up and dump it to disk somewhere(user home might be a slightly better idea, since support for encrypting your home directory is slightly easier than for encrypting the entire disk); but if that isn't a requirement you probably don't want it touching the disk at all(unless you are in a very memory constrained and swapless environment where getting OOM killed every time something unexpectedly verbose happens would be really annoying).

Re:How is this *really* a problem? (0)

Anonymous Coward | more than 2 years ago | (#39290065)

(in thinking about the problem further:)

The question of where to put stuff on the disk is actually slightly more vexed than I had first considered: In a networked environment, /tmp, not /home is a good place for temporary stuff for a reason. /tmp is almost certainly just a dirt-cheap slab of local disk, while /home/username is probably on a fileserver somewhere, lovingly stored and backed up by your IT minions, and subject to network latency. That's a lousy place for every program's random temporary crap. However, in a standalone installation, /tmp and /home are probably on the same disk, and that disk is more likely to be in a theft-prone laptop or similar. By default, encrypting /home is common and easy, encrypting the whole disk less so, so storing your various potentially-sensitive cruft somewhere in /home makes some sense.

Re:How is this *really* a problem? (4, Informative)

skids (119237) | more than 2 years ago | (#39288977)

It's a particular problem if you A) don't run on entirely encrypted partitions, and B) have your kit stolen or get rooted. Your biggest problem is that you had your kit stolen or got rooted, however, this problem effects the damage control process.

Usually when you have a compromise you assume that only data that is "on the host" is compromised, and any data from other hosts is only compromised if it happened to be viewed after you got rooted (because the attacker could have been keylogging.) With cleartext from encrypted sessions hitting disk, this means that data could be sitting around in unused block in /tmp for years, so once you get rooted you have to assume everything ever done on other machines using a terminal on that machine has been exposed. So if you edited your corporate HQ's VPN PSK 2 years ago, that may still be on your disk.

tmp is less likely to be on an encrypted media than other filesystems, because it is usually expected to be a performance bottleneck.

The good news is that in many cases the data never got flushed back to disk and stayed in the filesystem buffers, but for high security concerns this is little consolation.

Green on black? (0)

Anonymous Coward | more than 2 years ago | (#39288743)

Just because it's a bug report for a terminal emulator, doesn't mean it has to look like it's in a terminal emulator...

Re:Green on black? (1)

suso (153703) | more than 2 years ago | (#39289133)

You're just saying that because you don't read climagic [twitter.com]

mrxvt (0)

Anonymous Coward | more than 2 years ago | (#39288765)

it rocks!

Doesn't sound like a flaw to me (1)

Anonymous Coward | more than 2 years ago | (#39288785)

This really sounds like how it was designed to work.

Thats what /tmp is for, after all, is it not? Sounds like the problem would be solved by partitioning different users data into seperate, appropriately secured /tmp files.

Is bash history a "flaw" too? I'm sure plenty of people don't know that it's a text file anybody with access to it can read.

Re:Doesn't sound like a flaw to me (1)

Cley Faye (1123605) | more than 2 years ago | (#39289001)

This really sounds like how it was designed to work.

Thats what /tmp is for, after all, is it not? Sounds like the problem would be solved by partitioning different users data into seperate, appropriately secured /tmp files.

Is bash history a "flaw" too? I'm sure plenty of people don't know that it's a text file anybody with access to it can read.

Bash history is a different kind of threat; it's only about what command you used. Sure, you could get a few hostnames from it, but no more.
Having your terminal session stored on disk mean that everything you see is suddenly on your filesystem, and staying on it if your /tmp is backed by the harddrive.

Re:Doesn't sound like a flaw to me (1)

Anonymous Coward | more than 2 years ago | (#39289107)

Some people execute commands that take a password as a command line argument.

Besides even that, you can learn a lot about a person from their .bash_history. More than just a few hostnames. You can make some inferences at least.

Re:Doesn't sound like a flaw to me (3, Insightful)

skids (119237) | more than 2 years ago | (#39289045)

People in the know know about cli history files. They don't necessarily expect data viewed in a terminal window to hit disk. It may or may not be a "flaw" depending on your opinion as to what appropriate security measures amount to, but it's worth an awareness campaign.

tmpfs (4, Insightful)

Sloppy (14984) | more than 2 years ago | (#39288797)

You are either encouraged to switch terminals and/or start using tmpfs for your /tmp partition until the library is fixed.

Once you go tmpfs, why would you ever go back, VTE flaws or not? tmpfs kicks ass.

Then encrypt your swap (random key every boot; you don't even need to know a key to be coerced from you) and you have a safe /tmp.

Re:tmpfs (1)

camperdave (969942) | more than 2 years ago | (#39289165)

In some countries, it is illegal for you not to divulge the key to properly warranted authorities - even if you don't know what it is.

Re:tmpfs (1)

X0563511 (793323) | more than 2 years ago | (#39289811)

Then set up a keyfile for swap and edit /etc/crypttab appropriately. If you're doing the rest right, your encrypted root will protect the swap then, as well - yet you can comply with law enforcement and hand over the keys if ordered., yet still helps protect you from the thieves and other asswipes.

Re:tmpfs (4, Informative)

Ceriel Nosforit (682174) | more than 2 years ago | (#39290815)

In some countries, it is illegal for you not to divulge the key to properly warranted authorities - even if you don't know what it is.

So what? In my country blasphemy is illegal. I'm not from the Middle East either, I'm a Finn. - Sometimes you just have to, grow a backbone, fuck Jesus in the ass and break the law.

Re:tmpfs (-1)

Anonymous Coward | more than 2 years ago | (#39291187)

Do you imply, that fucking jesus in his ass is blasphemy?

Re:tmpfs (0)

Anonymous Coward | more than 2 years ago | (#39289201)

I've witnessed apt fail because it filled up tmpfs, though.

Re:tmpfs (1)

gzipped_tar (1151931) | more than 2 years ago | (#39289237)

On a memory-limited system, one may not want /tmp kept as tmpfs in the RAM.

Re:tmpfs (1)

dalias (1978986) | more than 2 years ago | (#39289757)

It's not kept in ram. It's kept in virtual memory. Which might or might not be present in ram at any given time. Pretty much the same as data on the filesystem, which also might or might not be kept in ram at any given time.

Re:tmpfs (1)

GameboyRMH (1153867) | more than 2 years ago | (#39289827)

My N900 with only a quarter-gig RAM uses tmpfs and it doesn't cause any trouble.

Re:tmpfs (0)

Anonymous Coward | more than 2 years ago | (#39289303)

Once you go tmpfs, why would you ever go back, VTE flaws or not? tmpfs kicks ass.

Despite the whole flood thing, harddrive space is significantly cheaper than RAM. I've run into multiple situations where I need more space in /tmp than I have total RAM.

Assuming you have sufficient free RAM, sure, tmpfs is absolutely wonderful.

Re:tmpfs (0)

Anonymous Coward | more than 2 years ago | (#39290859)

Tmpfs overflows into swap, which can be encrypted easily. (There are, of course, alternatives available if you wish to avoid this behavior.)

Re:tmpfs (1)

Anonymous Coward | more than 2 years ago | (#39290157)

Encrypt swap? Who the hell uses swap these days?

Lets says you have a mere 4GB of RAM. A small swap file of say 512MB would be useless considering how much you already have but if you go to 1GB+ size swap files then your machine is going to grind to a halt (ie. become useless) if you start swapping that much memory.

Swap is useless and/or pointless if you have 2GB or more of RAM.

Re:tmpfs (1)

allo (1728082) | more than 2 years ago | (#39291227)

why? When processes get bigger and harddrives get faster, the swapfiles can grow as well.

Re:tmpfs (2)

MrNemesis (587188) | more than 2 years ago | (#39291649)

Swap files may grow, but the speed of hard drives doesn't scale along with everything else. Take a good platter-based drive and you're lucky to see reads/writes of 20MB/s assuming little to no HDD contention, especially since swap is typically highly random non-sequential 4k access. RAID that up or us an SSD and you might get 50MB/s. Lets say you have a 512MB swap, as I do, it'll take 10s to read the whole thing. Take a 512GB swap (like one poor server I found at work - someone was following the appallingly stone-aged adage about swap=mem*2) and all of a sudden it's going to take you 3 hours to read back all that virtual memory.

Compare that with some old memory, say some DDR-333, which has a transfer rate of over 2GB/s. Compare with the DDR3 in my workstation, capable of 12GB/s.

Back when we were limited to miniscule amount of memory, lots of swap made sense because memory was horrifically expensive and it didn't take *that* long to read/write to, because the total amount of memory was still fairly small in comparison. But these days you're looking at wait times of 30 minutes or more if you want your entire swap space to be double your memory and to be used by the OS.

Stick with a small swap file and not much crap ever gets written to disc, saving you the horror of having to reset a server for the umpteenth time when it's been grinding on its system disc for five minutes trying to page in the OOM killer.

Re:tmpfs (2)

Rashkae (59673) | more than 2 years ago | (#39291547)

*Sigh*, this again. No matter how much memory you have, some of it will end up with accumulated cruft that rarely needs to be read/changed. That ram would be better used freed up (swapped out) and used for cache instead. And 2 GB is nothing compared to a modern Desktop (gnome, Unity, KDE, take your pic.) If you do any kind of multitaking of large applications, you need a minimum of 8GB before you can be safely swap free.

Re:tmpfs (0)

Anonymous Coward | more than 2 years ago | (#39291687)

It's useful if you have a laptop you wish to hibernate, since the content of your RAM is dumped in the swap. I wish it was done in another way since swap is mostly useless for anything else, and this method for hibernation forces a ridiculously large swap-partition. :/

Re:tmpfs (1)

couchslug (175151) | more than 2 years ago | (#39290439)

"(you don't even need to know a key to be coerced from you)"

Great. That just means a longer beating from the proverbial XKCD Crescent wrench....

Cheers, Behdad Esfahbod, nice one (0)

Rogerborg (306625) | more than 2 years ago | (#39288833)

This guy, right [behdad.org] ?

Interesting choice of inspirational quote:

It is amazing what you can accomplish if you do not care who gets the credit. - Harry S Truman

The same applies to blame, Behdad.

Not a bug (5, Insightful)

Anonymous Coward | more than 2 years ago | (#39288873)

This is not a bug. This is exactly how /tmp is meant to be used. It is no different from sensitive data from your internet cache being stored on the hard drive.

If your garbage data is sensitive, you should encrypt /tmp, or mount a tmpfs there.

Re:Not a bug (1)

fluffythedestroyer (2586259) | more than 2 years ago | (#39289579)

The op never mentionned it was a bug. Just a flaw. There is a big difference between bug and flaw.

hello, this occurs with swap too (3, Informative)

WatchMaster (613677) | more than 2 years ago | (#39288947)

This is true of vi and many other programs. The exact same issue occurs with the swap partition.

Anyone can solve this problem, just mount /tmp and swap using dm-crypt with a new random password every reboot. The partitions are perfectly good while the computer is booted, but are inintelligible afterwards.

Re:hello, this occurs with swap too (0)

Anonymous Coward | more than 2 years ago | (#39289193)

Your swap partition, if you use it, should of course be encrypted. But there's not much point in having /tmp on an encrypted disk partition instead of in tmpfs. As long as it stays in RAM it will be written and read much faster, and if it is swapped to disk it will be encrypted anyway since the swap partition is encrypted. No information from /tmp will leak across reboots.

Re:hello, this occurs with swap too (1)

Barbara, not Barbie (721478) | more than 2 years ago | (#39292235)

... or just don't use swap. It's not like you need it any more. I'm running with no swap partition, no swap file, and even with openoffice and eclipse and firefox and opera open, I still use less than a gig of ram.

Of course, I also close firefox every day - it leaks memory.

Is konsole affected? (1)

fnj (64210) | more than 2 years ago | (#39288993)

Well?

Re:Is konsole affected? (3, Informative)

suso (153703) | more than 2 years ago | (#39289243)

I haven't had time to look into it completely, but when you have konsole set to unlimited scrollback mode, it will create files in /tmp/kde-username/konsole*.tmp that have your scrollback buffer. It is encoded somehow, but its there. I'm not sure if its encrypted or not. I found out about it because when I talked with the libvte developer (Behdad), he said that he looked at the code in Konsole to see how they did it before writing the implementation in libvte.

Re:Is konsole affected? (1)

CanHasDIY (1672858) | more than 2 years ago | (#39289397)

From TFA:

Note: I do not recommend konsole because it has the same issue with writing scrollback buffer to disk. It encodes the data so it is not as visible, but it would be trivial to decode that data.

Re:Is konsole affected? (2)

zeldor (180716) | more than 2 years ago | (#39290671)

It looks like only if the scrollback size is unlimited or at least really huge.
I have 1000 line scroll back and konsole creates no such files in /tmp.

My hard drive ... (1)

PPH (736903) | more than 2 years ago | (#39289013)

... contains lots of stuff much worse than scrollback buffers should some nefarious character manage to lay hands on it.

Aside from that, any /tmp (physical or volatile) can be a problem on a multiuser system if the app is dumb enough to create files with go+r permissions. If this isn't done, those files are as secure as any in my home directory.

Re:My hard drive ... (0)

Anonymous Coward | more than 2 years ago | (#39289275)

Here's what gnome-terminal does on my Ubuntu box:

1945 open("/tmp/vte7GW0AW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 30
1945 unlink("/tmp/vte7GW0AW") = 0
1945 open("/tmp/vte69W0AW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 30
1945 unlink("/tmp/vte69W0AW") = 0
1945 open("/tmp/vteF650AW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 30
1945 unlink("/tmp/vteF650AW")

So, files with 600 permission and unlinked right after creation. What's the problem again? Someone having unauthorized physical access to your machine can read your files if your disks are unencrypted? Well, duh.

Who doesn't have /tmp as a tmpfs at this point? (3, Interesting)

Mysticalfruit (533341) | more than 2 years ago | (#39289093)

considering how much /tmp gets used, having it in memory is one of the quickest ways to boost the performance of your system...

Re:Who doesn't have /tmp as a tmpfs at this point? (1)

Just Some Guy (3352) | more than 2 years ago | (#39291163)

With all the layers of caching between an application and the spinning drive, isn't /tmp (and every other filesystem) essentially in-memory anyway (at least for short-lived files)?

Re:Who doesn't have /tmp as a tmpfs at this point? (1)

Anonymous Coward | more than 2 years ago | (#39291469)

No. This is one of the more common misconceptions.

tmpfs is an entire filesystem in memory. It stores objects directly in memory. It is MUCH MUCH faster than a regular filesystem because its metadata keeping is much cleaner, simpler, and it is hot-cache-aware. This is speedup 1.

tmpfs does not have a backing store device other than swap, while a normal filesystem does. A normal filesystem HAS to evict dirty pages and metadata to the backing store, even if you created and destroyed a file before the writeback got to it, it will still generate IO eventually even if it is just for the metadata. This is tmpfs speedup number 2.

Thank you Solaris.... (0)

Anonymous Coward | more than 2 years ago | (#39289097)

For making /tmp out of the virtual memory pool - there is no *on disk* image to read. when the box is rebooted, /tmp is empty - always.

How is this is this different to shell history? (3, Insightful)

Viol8 (599362) | more than 2 years ago | (#39289255)

Various shells store command history as a .[shell name]_history file in the users home directory which can be left between sessions. Thats happened for years and root can view that too.

Sure, this may be a bug but frankly its a non issue.

Re:How is this is this different to shell history? (1)

gzipped_tar (1151931) | more than 2 years ago | (#39289353)

Shell history doesn't contains only input, not output.
Someone may have splashed some GPG private keys to the terminal, and the output ends up in the filesystem blocks.

Re:How is this is this different to shell history? (2)

truedfx (802492) | more than 2 years ago | (#39289591)

Aside from that, shell history doesn't contain anything not entered into the shell. Particularly, it doesn't contain anything entered into another remote shell.

Re:How is this is this different to shell history? (1)

Dcnjoe60 (682885) | more than 2 years ago | (#39289589)

Various shells store command history as a .[shell name]_history file in the users home directory which can be left between sessions. Thats happened for years and root can view that too.

Sure, this may be a bug but frankly its a non issue.

It might not be a high risk issue, but it probably should still be fixed.

Re:How is this is this different to shell history? (0)

behdad (320171) | more than 2 years ago | (#39291553)

And I offered to fix it, but the reporter decided to ignore that and public the report, claiming that I said I won't fix it. I think the slashdot bragging rights were more interesting to him. :)

Re:How is this is this different to shell history? (0)

Anonymous Coward | more than 2 years ago | (#39292317)

Well it's pretty obvious that it's more important to him than security in GNOME is to you. Regardless of his intentions it doesn't make your response any less irresponsible and lacking in professionalism. I'm glad this went public, the fact that people like you are "working" on GNOME should be made available to the public so they know the risks they're taking by using your code.

That is, unless you're going to stop your pointless bickering and finger-pointing and fix libVTE instead of scrambling all over Slashdot trying to justify your poor decisions?

Re:How is this is this different to shell history? (0)

Anonymous Coward | more than 2 years ago | (#39290619)

Shell history, on my machines at least, contains only the commands processed in that shell terminal. So 'cd', 'ls', 'passwd' and the like will all be there, but not the output of those commands. This is returning both the commands and the output of them, buffer..., which depending on how you look at it, shouldn't be occurring. Especially since, when running sync, as the he does in the video, it should clear the buffer content if it does exist on the fs, yet clearly the buffer output shows up in tmpfs.

Is this actually a bug? Yes, and no. If it is entirely dependent upon how tmpfs is set up, this is a configuration bug which should either be dealt with in practice, or a software solution workaround be put in place.

Nothing to see here ... (1)

dgharmon (2564621) | more than 2 years ago | (#39289511)

Nothing to see here, and moving on .. so you have access to the tmp directory which may have a record of what you viewed during the session ...

What about Konsole? (1)

Dcnjoe60 (682885) | more than 2 years ago | (#39289581)

Does this impact KDE's Konsole, too?

Re:What about Konsole? (0)

Anonymous Coward | more than 2 years ago | (#39289633)

h.a.y.r.t.f.a.

Re:What about Konsole? (1)

bvimo (780026) | more than 2 years ago | (#39290349)

Have a read of this fine reply earlier http://linux.slashdot.org/comments.pl?sid=2714201&cid=39288993 [slashdot.org] .

Re:What about Konsole? (1)

Dcnjoe60 (682885) | more than 2 years ago | (#39291091)

Yeah, I saw that after I posted,

XTerm FTW! (1)

denvergeek (1184943) | more than 2 years ago | (#39289655)

Now get of my lawn!

Re:XTerm FTW! (1)

denvergeek (1184943) | more than 2 years ago | (#39289667)

That should be "off". Now get off my lawn!

Re:XTerm FTW! (0)

Anonymous Coward | more than 2 years ago | (#39289997)

Agreed. I just wish CLIPBOARD was fixed by default everywhere.

but but but... (0)

Anonymous Coward | more than 2 years ago | (#39289845)

I thought linux systems were bulletproof ?!

mrxvt FTW! (0)

Anonymous Coward | more than 2 years ago | (#39289867)

ever since MGT withered on the vine.

I'd be a little miffed (5, Insightful)

DarkOx (621550) | more than 2 years ago | (#39289959)

If I were the author of this library I'd be a little annoyed. The article is written as if the library does something wrong. It does not. It stores data on /tmp, which is there to be used as scratch space. To read the file you have to be the owner or root, which has been true of every process that has written there since before my years. This is perfect correct.

Okay some uses might not expected their terminal emulator to keep temporary files. Yes if your disk is appropriated someone not root in your environment might be able to read it. Which is true of basically any process that writes anything to disk anywhere; even ones that don't. Suppose my system is under enough VM pressure that my good old fashion xterm gets paged out? Why scroll back buffer data, which might even have come from SSH would be right there on my disk! OH! NOS!

If you are dealing with a system that is physically insecure, like a laptop, or machine in a public spot, or information that is so sensitive you'd be more concerned about it being out there than the fact that your hard disk or entire system has gone missing; there is a solution for that. Its called disk encryption! If you use Linux it won't even cost you anything!

Re:I'd be a little miffed (0)

Anonymous Coward | more than 2 years ago | (#39290461)

I agree.

There's nothing wrong with the library's implementation.

Does the author of the article expect magic of some sort here?
I get it - he should have wrote the tmp file to /dev/magic.
If anything, the author of the library should get an apology.

This is a low-quality non-issue by someone wanting to make a
name for himself, IMHO.

Re:I'd be a little miffed (-1, Troll)

Anonymous Coward | more than 2 years ago | (#39291397)

Yeah, try reading said author's reactions to this with a straight face:

https://bugzilla.gnome.org/show_bug.cgi?id=664611 [gnome.org]

He's basically saying that if anyone complains about the bug further he'll take his ball and go home like a little child. This is a security issue that affects anyone using his buggy code, not just an insult to his over-inflated ego, but that's exactly how he's treating it. No small wonder that no one will take GNOME developers seriously any more, they have the mentality of children with anger management issues.

Re:I'd be a little miffed (1)

behdad (320171) | more than 2 years ago | (#39291747)

See my other comment also:

http://linux.slashdot.org/comments.pl?sid=2714201&cid=39291633 [slashdot.org]

Re:I'd be a little miffed (-1)

Anonymous Coward | more than 2 years ago | (#39292201)

And see https://bugzilla.gnome.org/show_bug.cgi?id=664611 [gnome.org] for an example of what Behdad is really like when confronted, not just the PR nonsense he's smearing the comments of this thread with. The _real_ story is that because his fragile ego has been insulted, every machine with libVTE installed is going to remain vulnerable to this bug. He simply doesn't care. It's a level of irresponsibility that's unique even for the GNOME team.

Better yet, behdad@gnome.org and slashdot@behdad.org to ask when this man-child is actually going to fix the code he's made everyone's systems vulnerable with. I'm sure his input on the situation would be amusing.

Yet another reason to switch to KDE permanently. (0, Informative)

Anonymous Coward | more than 2 years ago | (#39290195)

Just take a look at what the GNOME developers call "community relations" these days:

https://bugzilla.gnome.org/show_bug.cgi?id=664611 [gnome.org]

The very first person that tries to protest the lack of response by the VTE developers gets his account disabled immediately. And people wonder why GNOME 3 is such a clusterfuck, it's full of people like Behdad.

Re:Yet another reason to switch to KDE permanently (4, Informative)

behdad (320171) | more than 2 years ago | (#39291633)

Anonymous Coward,

You may want to read the end of this comment before jumping to conclusions:

    https://bugzilla.gnome.org/show_bug.cgi?id=664611#c10 [gnome.org]

Ie. I offered to fix it, before the report was published. And the report is deliberately misinformed to make it look like I said I don't have any intention to fix it. And the report author tweetted [1] "Apparently not a lot of people read Slashdot anymore or RTFA. I've only had 971 hits to the article so far. :-(", which makes me believe that his true intention was to get Slashdot / Reddit / Hacker News bragging rights. Comes handy if you are a sysadmin I guess...

behdad

[1] https://twitter.com/#!/climagic/status/177796284755873793 [twitter.com]

Re:Yet another reason to switch to KDE permanently (0)

Anonymous Coward | more than 2 years ago | (#39292167)

I have read the thread, actually, and I saw your childish non-responses that resulted in this blowing up in the first place. As far as I'm concerned the motivations of the author don't matter, and they shouldn't matter to _YOU_ either. If the bug still exists, and it does, you should be _IGNORING_ his intentions and working on fixing the security vulnerability, not scurrying about on Slashdot trying to defend yourself when you've already proven your position indefensible.

I'm personally quite glad that I switched to KDE 4.8. It's stable, offers more features than GNOME 3 ever _will_ offer, and best of all, Behdad? It doesn't have people like you working on it, which means that a security vulnerability will be given the attention it's due, not put on the backburner because somebody on the Internet hurt your feelings. Grow the hell up. You've embarrassed yourself enough already, time to either fix your damn code or step aside and let someone more capable do the job.

Scrollback is for noobs (2)

trev.norris (2010080) | more than 2 years ago | (#39290657)

Seriously. Disable scrollback and use screen. You're life will improve.

If an attacker is reading plaintext off a drive... (1)

DamnStupidElf (649844) | more than 2 years ago | (#39290683)

..that you once owned, you have a much bigger problem than your scrollback buffer.

AES-NI makes encryption almost free. There's no reason not to use it.

What about putty? (0)

Anonymous Coward | more than 2 years ago | (#39291591)

sudo apt-get install putty?

Ever heard of swap? (1)

sjames (1099) | more than 2 years ago | (#39291631)

This is truly a non-issue. If your machine has swap, then ANYTHING in memory can end up on the disk. The data is not exposed in a way that it can be grabbed by other users, you would have to dig through the disk image to find the unlinked file.

Very simply, if you ever dispose of or sell a hard drive, you MUST wipe it first. If a drive fails and you want to make sure no data gets out when you throw it away, you must destroy the platters.

SSH has nothing to do with this. It is not and never was a magic faery wand that prevents data disclosure. Once the data gets from remote to local, its job is done.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>